The device/API-abuse cure

A valid-looking FHIR API caller, or a device sitting on the clinical network, is trusted because it is reachable, not because it authenticated. That is the whole abuse. It has an OWASP name, BOLA, because the token authenticates a claim, never the machine on the other end.

Whisper closes it by making the address be the device: a routable IPv6 /128 derived from the key the endpoint or device already holds, DNSSEC-anchored and DANE-pinned, that no caller can forge and one call can revoke worldwide. Unlike the certificate binding UDAP asserts inside a private trust community, it is publicly verifiable across the HDO / vendor / HIE boundary. A stolen token or over-broad scope with no device key behind it authenticates to nothing. This page walks through the abuse end-to-end, the reframe at the reachability layer, the exact live calls (keyless to verify, one keyed call to provision), and, candidly, what identity does and does not cure.

The abuse, at class level

It is not a breach. Your FHIR API and your clinical network are used exactly as they were built, at scale, by a caller no one authenticated.

The mechanics repeat across the sector. A third party reverse-engineers an mHealth or clinician app, increasingly with an LLM's help, until it holds the exact calls the official app makes, then authenticates the same ways the app does: a phished login, a hardcoded key lifted from the app bundle (found in roughly three-quarters of one 30-app set), an over-broad SMART-on-FHIR scope, or an OAuth bearer token portable to any IP. From there it is BOLA: increment the patient id and read the next record, an implementation flaw HL7 has publicly and correctly distinguished from the FHIR standard, yet one found in every production FHIR API in the small set one researcher tested at DEF CON. On the device side the story is quieter and older: land on the flat, converged clinical VLAN, where HL7v2 feeds, unauthenticated DICOM, and proprietary device protocols assume anything on the LAN is trusted. Internet scans keep finding thousands of open DICOM servers that answer without AE-Title validation, exposing well over a billion images.

Two facts hide it at the network layer. A real integration is one endpoint an org owns; the abuser is one caller trusted only by reachability, holding a valid credential. And the egress hops across clouds or a residential-proxy swarm every few requests, so a security operations center correlates a fresh, meaningless last IP and nothing else. Increasingly the caller that matters is not even on your network: more than 40% of 2024 healthcare breaches began with a third-party vendor, and a credential burned at one organization is reusable against the next, because nothing revokes it across the boundary. That is why an incident here is now a measurable patient-safety event, not only a data one.

The reframe: the address is the device

Detection will always be a step behind a credential that is genuinely valid. You can tune models forever and the abuser still looks exactly like a trusted integration: to your endpoint, it is one. The strictly-stronger move is to change what the exchange trusts, at the layer where the abuse actually lives: reachability.

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-signed to the IANA root, DANE-EE pinned (3 1 1), and RDAP-registered. Anyone can re-derive and verify it with dig.

Point it at the endpoint and the device. Whisper derives the /128 for each FHIR endpoint (or each infusion pump, monitor, or PACS node) 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 registered in GUDID), a DICOM AE-Title's PS3.15 TLS certificate, an ISO/IEEE 11073 EUI-64, or a TPM / secure element. The Endpoint.identifier or UDI serves 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, and the derivation is tenant-bound: the same key and identifier always yield the same /128, and the mapping is unlinkable across organizations to an outsider. The exchange then authorizes on the endpoint's pinned identity, not a stealable token: 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.

The highest-leverage move for the API side is turning UDAP's private URI↔SAN assertion into a public one. UDAP's rule is exact and good: the identifying URI SHALL equal the server's {baseURL} and match a uniformResourceIdentifier in the certificate SAN, and /.well-known/udap returns signed_metadata (a JWS carrying the certificate chain in x5c). But that binding is rooted in a private community anchor (a TEFCA or state-HIE CA), so a relying party outside the community has nothing to check, and nothing anchors it in DNS. DANE (RFC 6698 TLSA) plus DNSSEC publish exactly that base-URL↔certificate binding at the IANA root, so any party verifies it with nothing pre-provisioned, and one dropped TLSA revokes it at DNS-TTL. It complements the community CA; it never replaces it.

What changes

Nothing here is a new detection rule. Each row is an abuse technique that stops being possible, not one you catch after the fact.

Provision a device or endpoint identity

Provisioning is one control-plane call to POST https://graph.whisper.security/api/query with your X-API-Key header. You pass the endpoint's or device's public key material (the base64 SubjectPublicKeyInfo of its UDAP server / IDevID / TPM / secure-element key) and the identifier it already carries as device_id: for a FHIR endpoint, its UDAP identifying URI (equal to the {baseURL} that the server certificate's SAN uniformResourceIdentifier asserts); for a device, its FDA UDI-DI or DICOM AE-Title. You get back the deterministic /128 and a WireGuard config to source that endpoint's traffic from its own address.

The call

CALL whisper.agents({op:'connect', args:{
  tier:'wireguard',
  identity_public_key:'<base64 SPKI of the endpoint or device key>',   # its UDAP server / IDevID / TPM / secure-element public key
  device_id:'https://fhir.example-hdo.org/r4'                    # the UDAP identifying URI = the FHIR {baseURL} the cert SAN asserts (or an FDA UDI-DI / DICOM AE-Title)
}}) YIELD op, ok, status, result, error
  RETURN op, ok, status, result, error

Over stock tools. jq builds the JSON body so the Cypher's own quotes never fight the shell:

# the public key only, the private key never leaves the device's secure element
Q="CALL whisper.agents({op:'connect', args:{tier:'wireguard', \
   identity_public_key:'MFkwEwYHKoZIzj0…SPKI', device_id:'https://fhir.example-hdo.org/r4'}}) \
   YIELD op, ok, status, result, error RETURN op, ok, status, result, error"

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  --data "$(jq -nc --arg q "$Q" '{query:$q}')"

The response

# result carries the deterministic identity plus a ready-to-apply tunnel
address        2a04:2a01:f0::fda
fqdn           endpoint-3f2504e0.fhir.<tenant>.agents.whisper.online
ptr            endpoint-3f2504e0.fhir.<tenant>.agents.whisper.online
state          active                       # DNSSEC + DANE-EE (3 1 1) live at provision time
wireguard_config   [Interface] …            # source the endpoint's traffic from its own /128

The endpoint now has a name it can prove and an address it egresses from. Reverse DNS resolves the /128 to that identity, a TLSA record pins the leaf key (the very certificate your UDAP {baseURL} SAN asserts), and RDAP registers the object under 2a04:2a01::/32, the full seven-proof chain, published atomically with the allocation.

Idempotency and errors

The call is deterministic and honest about conflicts: conservative in what it emits, liberal in what it accepts.

Revoke, worldwide

Decommission, a board swap, a transfer between organizations, or a compromised device is one call. It is provable with the same stock tools that proved the identity existed, no Whisper software required.

# the control-plane op…
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:f0::fda'}})
# …or the CLI
whisper kill --revoke 2a04:2a01:f0::fda

# now prove it, worldwide, at DNS-TTL speed:
dig -x 2a04:2a01:f0::fda +short                        # -> nothing
curl -s https://whisper.online/verify-identity/2a04:2a01:f0::fda
# -> {"is_whisper_agent": false, ...}

Verify it: keyless, no account

The identity is public by design, so anyone (a partner HIE, a QHIN onboarding you, an OCR auditor, a device PSIRT) can check an endpoint without your key and without taking Whisper's word for it. This is the keyless half of the two-tier surface: verify with no key, provision and govern with your key.

# no key, no account: re-derive and verify the endpoint's identity, trustless to the IANA root
whisper verify --trustless 2a04:2a01:f0::fda

# or with only curl: the keyless full-chain verdict
curl -s https://whisper.online/verify-identity/2a04:2a01:f0::fda
# { "is_whisper_agent": true, "dane_ok": true, "jws_ok": true, "evidence": { ... } }

# the address IS the endpoint: forward-confirmed reverse DNS names it
dig -x 2a04:2a01:f0::fda +short
# endpoint-3f2504e0.fhir.example-hdo.whisper.online.

# the registry object for the /128: RDAP, typed JSON
curl -s https://whisper.online/ip/2a04:2a01:f0::fda | jq '.handle, .parentHandle'
# "2A04:2A01:F0::FDA/128"
# "2A04:2A01::/32"

The --trustless flag is the point: nothing there calls back to Whisper's own API as an authority. The CLI re-derives the DNSSEC chain to the IANA root, on your machine, with your resolver. A partner outside your trust community can verify a FHIR endpoint without joining it. Full mechanics: Verify an agent and DANE & TLSA.

Name what already got in

Identity stops the next forgery. It does not name the operator behind the sessions already in your logs. The same platform back-traces them, and the attribution survives the rotation because it fingerprints the operator's infrastructure and tooling, not the ephemeral egress IP. That is the piece an in-hospital sensor structurally can't reach: it stops at your edge, while the caller that mattered was a third party from the start.

Take a suspect egress IP straight from your SOC or API-gateway logs and ask the graph who really operates it. This runs read-only over the same public graph API, with your key:

# who really operates a host, even behind a CDN or a cloud front
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(\"203.0.113.10\")"}'

The read-only verbs (identify, origins, walk, variants, history) run over that one endpoint against a live internet-infrastructure graph of fused BGP, DNS, WHOIS, TLS, hosting, and threat intelligence. Cloud rotation collapses through origins and walk, which cluster shared ASN, hosting, and certificate lineage into one infrastructure genealogy; a residential-proxy swarm collapses through a JA4 / JA3 client fingerprint that travels with the tooling, invisible to your API gateway because it lives in the TLS handshake; history gives a timeline over a suspect operator. Every answer is reproducible, replayable JSON: the paper trail an OCR or HIPAA finding needs, not a screenshot. Express "one source touching N distinct device / endpoint identities across two organizations in a window" as a query, not a ticket.

See who's reaching it and govern what it reaches

An identity you can prove is also one you can watch and constrain. Because every device and endpoint resolves through Whisper's own authoritative DNS and RDAP, the owner sees exactly who looked, governs precisely what each device may talk to, and keeps an auditable record of every issuance: three doors a private community directory never opened.

• Who checked this endpoint is a query. op:lookups (keyless, per-/128: GET /ip/<addr>/lookups) returns who resolved or RDAP-queried an identity: an early warning that someone is walking your FHIR endpoint directory or enumerating your device fleet, a reconnaissance tripwire before the scrape, not a post-mortem after it.
• 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. op:firewall allows / denies by host, cidr, or port; op:budget caps a device's traffic and arms a kill-switch. This is agentless L3 segmentation for the device that can't take a NAC agent: the exact control the HIPAA Security Rule NPRM's segmentation ask needs, and the containment that chokes C2 and exfil.
• Sign the exchange. Bind a FHIR response or a 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. See Sign agent outputs.
• 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: it is tamper-evident and cryptographically anchored today; independent third-party witnessing is the next step, and the log already speaks the C2SP witness protocol so an external witness can co-sign.

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. See Egress governance.

Honest scope: what it cures, and what it doesn't

This is device- and endpoint-identity at the IP / DNS / transport boundary. It is additive, and it is candid about its edges: over-claiming fails a QHIN architect's review, and it should.

What it cures. Possession of a stolen secret stops being sufficient: a hardcoded key, a long-lived token, or an over-broad SMART scope with no device key behind it authenticates to nothing. UDAP's private base-URL↔certificate binding becomes publicly verifiable, shrinking token-replay and rogue-aggregator risk across the community boundary. Attribution survives egress and IP rotation and reaches across organizations. Revocation is cross-organization, at DNS-TTL. Egress governance constrains who a device may reach and be reached by, cutting C2 and exfil paths. And the per-/128, UDI-keyed identity plus the attribution graph are the asset-identity and network-map evidence FDA §524B and the HIPAA Security Rule NPRM ask for.

What it plainly does not cure.

• It is not human MFA. It provides device / endpoint entity authentication (which maps to HIPAA §164.312(d)), not authentication of a human user or a clinical session. Calling it MFA would be a mis-map; we don't.
• It does not authenticate 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 between two same-segment nodes, 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 stop an insider or a valid, authenticated session used maliciously, and it does not stop ransomware already executing locally: it governs network trust and egress, so it chokes C2 and exfil and speeds cross-org revocation, but it does not police what an already-trusted local process does on the box.
• It does not patch the unpatchable CVE. A URGENT-11 or Ripple20 stack flaw stays exploitable on-path; identity reduces who can reach the vulnerable device and attributes the traffic, it does not remove the bug.
• An identity is only as forge-proof as the device's key custody. An EOL device with no TPM or secure element inherits weaker assurance. We say so, rather than imply otherwise.
• It is not an SBOM (FDA §524B(b)(3)), encryption at rest, vulnerability scanning, or secure boot.

Additive, never a replacement. It complements, never replaces, UDAP / SMART / TEFCA trust, OAuth, your OEM's build-time device PKI, your network segmentation, and your device patching and lifecycle. It rides on top of the anchors you already ship, and it is built to fail open: a Whisper outage never bricks a device, checks degrade to the anchors you already run, and connectivity is preserved.

Where it fits: standards, SIEM, integrations

Compliance. The forge-proof, UDI-keyed per-device identity is a canonical asset-inventory anchor and its attribution graph is a live network map: direct evidence for three of the HIPAA Security Rule NPRM's hardest asks (asset inventory, network map, segmentation), plus entity authentication and an egress audit trail under §164.312(a)/(b)/(d). For a device maker, it is a built-in authentication and unauthorised-access control to point to in an FDA §524B(b)(2) security architecture, with demonstrable postmarket containment (a stable per-device identity and one-call revocation) for §524B(b)(1) and coordinated vulnerability disclosure, keyed to the UDI already in labelling and GUDID. It also maps to EU MDR Annex I §17.4 and IEC 62443 FR1. The clause-by-clause mapping lives in FDA 524B · HIPAA · MDR.

Integrations (proposed, not vendor-endorsed). Whisper anchors the cloud, API, and IP boundary, never the in-hospital clinical bus, the device's on-box command path, or a legacy protocol authenticator:

• UDAP / SMART on FHIR. DANE-pin the same server certificate your {baseURL} SAN already asserts, so a relying party outside your community verifies it against DNS with nothing pre-provisioned, and revokes at DNS-TTL. Complements the community CA and OAuth trust; replaces neither.
• FHIR Endpoint resource + TEFCA / QHIN / RCE & NDH directory. An Endpoint.address is a url (DNS-addressable by construction), so a Whisper name or /128 makes a directory listing self-verifying against the address, answering the ONC FAST finding that there is "neither an authoritative source for digital contact information nor a consistent method for locating it."
• FDA UDI / GUDID. Key the /128 to the Device Identifier so identity, traceability, and recall align. A physical device usually can't present its UDI on the wire, so the UDI→/128 binding joins through your IoMT-visibility inventory (Claroty, Armis, Forescout, Ordr, Palo Alto Medical IoT): a partnership seam, additive to their discovery, not a replacement for it.
• ISO/IEEE 11073 & DICOM PS3.15. Derive the /128 from an 11073 EUI-64 or a DICOM AE-Title's PS3.15 TLS certificate, turning an AE-Title→IP mapping that today is "set by installation personnel" and unauthenticated into a DNSSEC / DANE-verifiable one.
• OEM device PKI (e.g. a Medcrypt-issued leaf). Keep the manufacturer's build-time cryptographic identity; publicly anchor the operating hospital's or HIE's ability to look it up and revoke it in one call. The publicly verifiable, DNSSEC-anchored layer on top of the silicon identity you already stamp.

Next

• Device & FHIR-endpoint identity: how the /128 is derived from the endpoint or device key and its identifier, in depth
• Control plane: the full whisper.agents op set the provisioning call belongs to
• FDA 524B · HIPAA · MDR: the clause-by-clause evidence mapping