Your clinical network runs on machines built to be trusted, not to prove who they are.
Tens of thousands of them — pumps, monitors, scanners, EHR and FHIR endpoints — on flat clinical VLANs, most on operating systems too old to patch or run an agent. Every one authenticates a claim: a bearer token, a shared credential, a same-subnet IP — never the machine on the other end. So a phished login, a key lifted from an app bundle, or an over-broad OAuth scope walks the FHIR API and the DICOM port, scrapes a population of records, and rotates egress across Amazon, Google and Azure until all your SOC ever logs is a meaningless last IP. It is a HIPAA and GDPR exposure, and — increasingly — a patient-safety one.
whisper verify --trustless — anchored at the IANA DNS root. Our own API is not in the trust path.
It isn't a breach. Your own machines and APIs are used exactly as built — by someone they can't tell from a peer.
No zero-day required. Three surfaces stack the same failure — a device that authenticates a claim, not a machine — and a single operator walks straight through them.
The device default: trusted, not authenticated
Device lifecycles run 10–20 years against 3–5 years of OS support, so many sit on end-of-life systems that can't be patched or run an agent — ~60% of health systems say they can't protect their unpatchable, agentless devices. On a flat clinical VLAN, with IT/OT/IoMT converged, the controller, the EHR, the API each trust a token, a shared credential, or a same-subnet IP. A stolen secret simply is the device.
The FHIR API surface: a claim, not a machine
The data layer is a modern REST API and inherits REST's worst failure mode. SMART-on-FHIR issues OAuth scopes that are routinely over-broad; UDAP adds dynamic client registration; a mis-scoped or replayed token then walks the records — change the patient ID, read the next patient (OWASP BOLA). One study of production FHIR APIs found the flaw in every one it tested, and hardcoded keys in 77% of 30 mHealth apps. HL7 is right that this is an implementation flaw, not the FHIR standard — which is exactly why an identity anchor, not a spec change, closes it.
Legacy protocols: no auth at all
Beneath the API sit protocols that assume a trusted LAN and authenticate nothing. HL7v2 flows in the clear. DICOM AE-Titles are set by hand at install and unverified — scans find open DICOM servers exposing over a billion images, under 1% over TLS, ~99.5% accepting connections with no AE-Title validation. Proprietary device protocols are no better. On a flat segment, whoever can reach the port is trusted.
The kill chain — one operator, straight through all three
Find an exposed endpoint
An internet-reachable FHIR base URL or an open DICOM port — thousands of them, most accepting connections with no AE-Title validation at all.
Default, weak, or over-broad
A default password, a hardcoded key from an app bundle, or an over-broad SMART-on-FHIR scope / mis-scoped token. Auth says yes; nothing behind it is a machine.
Cross the IT/OT/IoMT bridge
Land on the flat, converged clinical segment where the imaging network, the pumps, and the EHR share trust — the convergence bridge does the pivoting for you.
Flat-network IP-trust, defeated
A pump, a PACS, an endpoint authenticates a claim — a same-VLAN IP, a shared cred. Present it and you are the device. Nothing checks a key.
Scrape PHI or move an order
Walk records via FHIR BOLA, pull exams over unauth DICOM C-STORE, or manipulate an infusion or imaging order. Legitimate-looking, at population scale.
No attribution, then cross-org
Egress hops clouds and residential proxies — a fresh last IP, nothing to correlate. Then reuse the loot at organization B: a credential burned at A still works, because there is no cross-org revocation.
Invisible by design: a clinician's app is one session to one record; the abuser is one operator to a whole population — holding valid credentials, showing you a disposable address every few requests, reusing at org B what it burned at org A. And the stakes are physical, at the class level: peer-reviewed Medicare-claims research finds in-hospital mortality rises 35–41% for patients already admitted when a ransomware attack begins, and neighboring emergency departments degrade as ambulances divert. A single third-party clearinghouse compromise cascaded nationally to roughly 190 million individuals — about a third of all US records, the largest healthcare breach on record. Healthcare has been the costliest industry to breach for 14 consecutive years.
Stop detecting the abuse. Prove the identity.
Detection will always be a step behind a credential that is genuinely valid. You can tune anomaly models forever and the abuser still looks exactly like a peer — because, to your endpoint, it is one. The only strictly-stronger move is to change what the endpoint trusts.
A session token, an OAuth scope, an API key, a same-subnet IP — whoever holds it can present it. That is the whole problem in one line: the credential proves a claim, never which device or which endpoint is on the other end, so a stolen one is indistinguishable from the real thing — and the source IP that might have narrowed it is disposable.
Tomorrow · the endpoint authorizes a machine that proves itself. Bind authority to an identity the device or FHIR endpoint holds and can demonstrate cryptographically, not a secret anyone can copy. Now a request either proves it is the endpoint it claims to be — before a single detection rule runs — or it has no authority at all. Detection stops being the last line of defense and becomes a bonus.
That identity already has a home on the networks that connect your HDO, your device vendors, and your HIE partners: an address. Here is how an endpoint's own key becomes an address no one can forge — and, unlike UDAP's private trust, one that verifies across every one of those org boundaries.
The key already in the endpoint becomes an address only that endpoint can prove.
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.
Point it at the endpoint. Derive each FHIR endpoint's — or each device's — /128 from the public key it already holds: the UDAP server-cert key that anchors its base URL, the device's secure element, a TPM, an 802.1AR-style IDevID — with the FHIR Endpoint.identifier or the FDA UDI (Device Identifier) 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 the endpoint or device already carries. (For an ISO/IEEE 11073 point-of-care device already named by a 64-bit EUI-64, that hardware identity is simply one more native identifier it can pass as its device_id domain separator — the address stays a one-way function of the device's key and that identifier, never the EUI-64 in the clear.)
"Scrape one endpoint → the whole HIE" becomes impossible
You cannot present thousands of endpoint 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 hardcoded keys fail
A replayed OAuth token or a key lifted from an app bundle, with no endpoint key behind it, authenticates to nothing. The endpoint checks the machine, not the bearer.
One revoke kills a compromised identity everywhere
At DNS-TTL speed, across every relying party and organization: dig -x returns nothing, verify returns false. The cross-org off-switch UDAP's CRL/OCSP never delivered.
"UDAP already gives our FHIR endpoints X.509 identity. Why isn't that enough?"
Because it can't be verified outside your community, and revocation is slow and anchor-scoped. UDAP's identifying URI is the FHIR base URL, which SHALL match a uniformResourceIdentifier in the server cert's SubjectAltName — a real, good binding. But it lives in a private community CA, is trusted only by parties provisioned with that anchor, and revokes via in-community CRL/OCSP. Whisper keeps the exact binding, DANE-pins it into DNSSEC, so a relying party who never joined your community verifies it against the DNS root — and one revoke drops it for everyone at DNS-TTL.
Endpoint.identifier is the public index — the /128 is its cryptographic counterpart. The identifier and base URL flow through every directory (TEFCA/RCE, the National Directory) — good for interoperability, but not a secret. The /128 is bound to the endpoint's key and its identifier, so the identifier alone yields nothing: you cannot go Endpoint.identifier → /128 without the key, there is no enumerable directory, and RDAP/reverse-DNS return the registry object, never the endpoint's whereabouts. Because the derivation is tenant-bound, the same device under two HDOs yields two unrelated /128s — no one can link a unit across organizations.Endpoint.identifier that hardens what UDAP already asserts. It never reaches into HL7v2 on the clinical bus, an unauthenticated DICOM association between two same-segment nodes, or a device's own on-board command path — those stay a segmentation and protocol-auth problem. Complements, never replaces.revoke. A board swap or module replacement re-keys to a new /128 and revokes the old one; a decommission or a change of custodian is one revoke and a re-register to the new owner. Compromise one device and you've compromised that device, not the fleet. 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 anchored to Bitcoin via OpenTimestamps — an auditable issuance trail for your regulator. Honest status: tamper-evident today; independent witnessing is the next step.Maps to FDA §524B(b)(1)/(b)(2) authentication + postmarket-containment evidence, the HIPAA Security Rule NPRM's asset-inventory / network-map / segmentation / §164.312(a)(d) entity-authentication asks, 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 enumerating your endpoints — and govern what each device may reach.
An identity you can prove is also one you can watch. Because every endpoint's name resolves through Whisper's own authoritative DNS and RDAP, the owner sees exactly who looked — a reconnaissance tripwire the community directory never gave you — and can govern precisely what each device may talk to.
Who checked this endpoint is a query
op:lookups (and the keyless /ip/<addr>/lookups) returns who resolved or RDAP-queried an endpoint's identity — an early warning that someone is enumerating your FHIR endpoints, before the scrape, not a post-mortem after it. Shipped & live.
Govern what each device may reach
A graph-first resolver and source-bound egress enforce default-deny per device — allow the EHR and the vendor's update endpoint, block everything else, by name or subnet. Agentless L3 segmentation for the machines that can't take a NAC agent — direct substance for the HIPAA NPRM network-map + segmentation asks.
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 telemetry & orders
Sign a device's outputs to its forge-proof /128 so a downstream system, an auditor, or an FDA postmarket review can trust an infusion log or an imaging order came from the real device — not a spoof on the segment.
The same address-is-identity primitive that governs a compromised pump also governs the AI agents your HDO is about to run against PHI — per-agent /128, per-agent logs, default-deny egress, one revoke. From day one.
Identity stops the next forgery. The graph names whoever already scraped you.
You won't re-key every endpoint by Monday, and there is abuse in your logs right now — 41% of 2024 healthcare breaches started with a third-party vendor. So the same platform back-traces the operator behind the sessions you already logged — attribution that survives the rotation and crosses the organization boundary your inventory tools can't see past.
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 the graph 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 regardless of the exit and collapses the swarm to one operator.
And it's a question, not a signature. Express the abuse directly — "one source touching N distinct endpoint- or device-identities across orgs in a window" — as read-only Cypher, and the graph returns the operator with a reproducible evidence chain your SOC, your PSIRT, an OCR investigator and a regulator can replay. That's rogue-aggregator and BOLA scraping caught by its shape across the fleet, not by a pattern you had to know in advance.
# ask the graph the business-logic question directly — read-only Cypher over the public graph API
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
-H 'content-type: application/json' -d '{"query":"MATCH (src)-[t:TOUCHED]->(e:EndpointIdentity)
WHERE t.window = \"15m\" WITH src, count(DISTINCT e) AS endpoints
WHERE endpoints > 25 RETURN src, endpoints ORDER BY endpoints DESC"}'
operator <fingerprinted> 1 source → 1,204 distinct endpoints / 15m · across 3 HIE orgs
egress: AWS eu-central → GCP europe-w4 → Azure westeu (collapsed to 1)
ja4: same tooling across 41 residential exits → 1 operator
reproducible, replayable JSON evidence chain → your SIEM"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 — so the rotation that hides them from your SOC is exactly what the graph reads through, and it reaches across the org boundary your inventory tools stop at.
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 over a suspect operator). Every answer is reproducible, replayable JSON: the HIPAA and GDPR paper trail for an unauthorized-aggregator finding, not a screenshot.
Identity is the cure; the graph is how you clean up what got in before it — and catch the operator who tries anyway, even across organizations. Detection made durable, on top of a root-cause fix.
What this does — and, just as plainly, what it doesn't.
This is an identity, attribution and reachability control. It is powerful precisely because it is narrow, so here is the honest boundary — the same one we'd want asked in a review.
What it governs
- WHO may reach and speak to a device or FHIR endpoint — egress governance + reachability.
- Kills stolen-static-credential and hardcoded-key possession — a secret alone no longer suffices.
- A publicly verifiable endpoint anchor that shrinks token-replay and rogue-aggregator scraping across orgs.
- Attribution that survives egress/IP rotation and crosses the organization boundary.
- Cross-org revocation at DNS-TTL — a credential burned at org A stops verifying against org B.
- The forge-proof asset-identity + issuance evidence FDA §524B and the HIPAA NPRM inventory/segmentation asks demand.
What it does NOT do
- Does not stop a purely internal, unauthenticated-protocol manipulation once an attacker is already on the clinical segment — an HL7v2 injection or an unauth DICOM C-STORE between two same-segment nodes is a segmentation + protocol-auth problem; in-path enforcement is still needed.
- Is device/endpoint identity, not human MFA and not user authentication — it proves which machine is on the wire, never who the clinician is; it does not satisfy the NPRM's MFA ask for human logins.
- Does not patch the unpatchable CVE — URGENT-11 / Ripple20-class flaws stay exploitable on-path; it reduces who can reach the device and attributes them, it does not fix the bug.
- Identity is only as forge-proof as key custody — an end-of-life device with no TPM or secure element has weaker key storage, and we say so.
- Provides no §524B SBOM, encryption-at-rest, vuln-scanning or pen-testing — those stay yours.
In one line: an identity, attribution and reachability control — complementary to network segmentation, device patching and lifecycle, and protocol-level authentication of legacy clinical traffic. Additive by construction. The HIPAA NPRM is directional, not yet final — the current-law hooks are §164.312(a)/(b)/(d)/(e) and the §164.308 risk analysis.
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 see who's been checking it — trustless, anchored at the IANA root. Your key: bind a device to the identifier it carries, govern its egress, back-trace a rogue caller, revoke it worldwide.
# keyless — re-derive and verify any device or FHIR endpoint identity, trustless
$ whisper verify --trustless 2a04:2a01:9a::f417
✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA 3 1 1) leaf matches the endpoint's UDAP server cert
✓ 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 (the Endpoint.identifier)
$ dig -x 2a04:2a01:9a::f417 +short
fhir.example-hie.whisper.online.
# who's been checking this endpoint — a recon tripwire, still no key
$ curl -s https://whisper.online/ip/2a04:2a01:9a::f417/lookups | jq '.recent[0]'
{ "kind":"TLSA", "from_asn":"AS…", "note":"someone is enumerating your FHIR endpoints" }
# who really operates a suspicious caller — with your key, via the public graph API
$ 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 (or a device) to the 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" \
-H 'content-type: application/json' --data @- <<'JSON'
{"query":"CALL whisper.agents({op:'connect', args:{tier:'wireguard',
identity_public_key:'<base64 SPKI of the endpoint/device key>',
device_id:'2.16.840.1.113883.3.72.5.2'}}) YIELD op,ok,status,result,error
RETURN op,ok,status,result,error"}
JSON
→ identity 2a04:2a01:9a::f417 DNSSEC + DANE-EE live # device_id = Endpoint.identifier (or the FDA UDI)
$ whisper policy set --default deny --allow ehr.example-hdo.org,updates.vendor.example
$ whisper kill --revoke 2a04:2a01:9a::f417 # worldwide, at DNS-TTL — across every relying partyAdditive to your IoMT platform. Mapped to your standards. Priced so you can say yes.
Your IoMT visibility tool tells you what is on the network and infers identity from behavior, inside one organization's console — necessary, and where that picture stops. UDAP proves endpoints inside a private community anchor. Whisper adds the two layers no one else owns: a publicly verifiable, DNS/DANE-anchored device and endpoint identity, and cross-organization attribution across rotating egress. It's depth on top of the stack you already run — not a console your analysts babysit.
| IoMT visibility | FHIR / UDAP endpoint trust | Whisper | |
|---|---|---|---|
| Medical-device asset discovery & inventory | ✓ | — | additive (consumes UDI as device_id) |
| Publicly verifiable DNS/DANE-anchored device/endpoint identity | — | partial (private anchor) | ✓ |
| Cross-organization attribution across rotating egress | — | — | ✓ |
| Cross-org revocation at DNS-TTL of a routable identity | — | partial (CRL/OCSP) | ✓ |
Feeds your SIEM and PSIRT
The Splunk, Microsoft Sentinel and OpenCTI connectors ship today. Findings arrive as signed, replayable JSON mapped to CEF and ECS fields — with STIX 2.1 over TAXII and H-ISAC export on the roadmap — that you can hand OCR or push straight into a PSIRT workflow.
Speaks your compliance language
Direct substance for FDA §524B(b)(1)/(b)(2) authentication + postmarket containment, three of the HIPAA NPRM's hardest asks — asset inventory, network map, segmentation — plus §164.312(a)/(d) entity auth, EU MDR Annex I §17.4, and IEC 62443 FR1. Honest: not SBOM, not human MFA, and the NPRM isn't final.
Additive to your IoMT platform
Plugs into Claroty, Armis, Forescout, Ordr, Palo Alto — consuming their inventory's UDI as the device_id — and publicly anchors a Medcrypt- or UDAP-issued leaf. No new appliance, no sensor vantage, no re-enrollment. It gives each device a forge-proof identity the platform can't mint.
Availability-safe by construction
It rides existing DNS/IPv6 and adds no inline clinical chokepoint. If your endpoint authorizes against the DANE/verify path, that plane is built to fail open — a Whisper outage never bricks a pump or a scanner; checks degrade to your existing anchors. Anycast on AS219419, no single node in the path.
On-prem or your own tenant
Data residency, HIPAA and GDPR by construction — the graph and the per-device logs stay where your regulator needs them. No PHI and no whole-fleet telemetry leaving your boundary to a third party you never contracted.
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. POC → pilot → enterprise, keyless to start — a flat, per-device line item, not per-transaction. See pricing →
Give every device an identity it can prove.
The address is the device — routable, DNSSEC-anchored, verifiable across the org boundary UDAP can't cross, revocable worldwide in one call. Keyless to try, one call to provision, one more to revoke. The device and FHIR-API abuse that no rate-limit ever caught simply runs out of forgeries.
Or run whisper verify --trustless right now.