Health compliance: FDA §524B, HIPAA & EU MDR

FDA §524B, the HIPAA Security Rule NPRM, FHIR/UDAP, TEFCA and the EU MDR all press a connected-health backend on one question: which device or endpoint is on this connection, is it authorised, and can you prove it and cut it off?

A device or FHIR server gated by a bearer token, a hard-coded key, or a shared address on a flat VLAN cannot answer that. A routable, DANE-provable, one-call-revocable IPv6 /128 per device or endpoint can. It produces the inventory anchor, the network map, the attribution and the kill-switch those frameworks want as evidence, not as a paragraph in a policy binder. This page is the honest map of where that evidence fits and, just as important, where it does not.

What every framework is really asking

Read the connected-health regulations side by side and the same three questions surface, phrased in a dozen vocabularies (OEM submission language, HDO security-rule language, HIE interoperability language):

• Identity: who or what is on the other end of this device-to-cloud or endpoint-to-endpoint connection, and can a third party (an HIE, an OCR investigator, an FDA reviewer) verify it without trusting your word for it?
• Attribution & monitoring: what did that party do, to which destinations, who is enumerating your fleet, and can you show a continuous, non-repudiable record across the HDO / vendor / HIE boundary?
• Response: when one device turns hostile, a credential is burned, or a vendor's access should end, can you contain it, provably and fast, across every organisation that trusted it?

None of these is a logging problem you fix with more log lines. They are identity problems: you cannot attribute, monitor or contain an actor that has no stable, provable identity in the first place. A FHIR Endpoint.identifier is a good business id, but it lives in a directory whose trust rests on a private community CA, is not self-verifying at the address, and revokes only via that community's CRL/OCSP. An FDA UDI is a universal device name, but it is a copyable string in a barcode, not a key. Whisper's job here is to give every device and endpoint on the cloud/IP boundary an identity that is addressable, publicly verifiable and revocable, then let the standard toolchain read the evidence off it.

Three verdicts, stated up front

Before a single row of the map, here is the grading rule. A health-compliance page that claimed to "make you §524B-compliant" or "satisfy the HIPAA Security Rule" would be lying. Whisper is a network primitive: against a given control it does exactly one of three things, and we mark which:

The evidence: real, and shipped

Everything this page grades DIRECT-ADDITIVE rests on primitives that exist and answer today. Each is checkable with dig, curl, or one control-plane call over the public API: POST https://graph.whisper.security/api/query with your X-API-Key.

A device- or endpoint-derived /128 identity

A device or FHIR server already holds a key: the public half of its UDAP server certificate, a DICOM node's PS3.15 TLS cert, an ISO/IEEE 11073 EUI-64, a TPM, or a secure element. Whisper derives a deterministic IPv6 /128 from that key's public SubjectPublicKeyInfo, with the FHIR Endpoint.identifier (or the FDA UDI Device Identifier) as the domain separator. The address is tenant-bound (fleet-unlinkable to an outsider), DNSSEC-anchored, DANE-EE 3 1 1 pinned, and RDAP-registered. Re-deriving from the same key and identifier yields the same /128; nothing new to store, nothing to steal that would let a scraper forge it.

# Provision a FHIR-endpoint identity from the key it already holds (control plane, live).
# identity_public_key is the base64 SPKI of the UDAP server / DICOM-TLS / TPM key.
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'   // the FHIR Endpoint.identifier (or the FDA UDI)
}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error
# -> deterministic /128 + a WireGuard config. Same key + identifier -> same /128 (idempotent).
#    A different identifier on the same tenant -> 409; a non-string device_id -> 400. Never a 500.

Per-/128 logs, and who's looking back

Because each device or endpoint owns a dedicated /128, every DNS lookup and connection it makes is unambiguously its: no shared-IP, flat-VLAN noise to reconstruct. And because the identity resolves through Whisper's own authoritative DNS and RDAP, you can also ask who is enumerating you, a reconnaissance tripwire the FHIR directory and GUDID never offered. In a sector where roughly two in five breaches originate with a third-party vendor, "who is verifying my endpoint, from where" is a cross-organisation early-warning signal no in-house appliance can see.

# The endpoint's OWN outbound activity: per-event timestamp, kind, destination, decision, bytes
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:f0::fda', kind:'conn', from:'-24h'}})

# Reverse observability: WHO resolved this endpoint's PTR/AAAA/TLSA or hit its RDAP object, and when
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:f0::fda', window:'24h'}})
curl -s https://whisper.online/ip/2a04:2a01:f0::fda/lookups | jq   # same view, keyless

One-call revoke

Containment (a compromised infusion pump, a burned credential, the end of a vendor's access) is a single call. It tears down the /128, its PTR and its DANE record worldwide at DNS-TTL speed, and the teardown is provable with the same public tools that proved the identity. This is the cross-organisation kill-switch a community CRL/OCSP never gave you: a credential burned at organisation A stops verifying against organisation B at the network layer, immediately and publicly.

CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:f0::fda'}})
# after the TTL:
dig -x 2a04:2a01:f0::fda +short                          # -> empty
curl -s https://whisper.online/verify-identity/2a04:2a01:f0::fda   # -> {"is_whisper_agent": false}

The attribution graph

Turning a raw destination (or a suspicious caller against your FHIR API) into "known-bad C2" or "clean CDN" is a read-only query against the public graph API. Attribution survives IP rotation because it fingerprints the operator and the tooling (ASN and hosting genealogy for cloud rotation, a JA4/JA3 client fingerprint for a residential-proxy swarm), not the ephemeral egress IP: the cross-organisation vantage an in-house IoMT sensor structurally cannot reach past one hospital's edge.

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  --data-urlencode "q=CALL whisper.identify('185.220.101.1')"
# -> what the address is, who operates it, threat-intel reputation, relationships:
#    a reproducible, replayable JSON evidence chain your HDO SOC, a vendor PSIRT and OCR can replay.

The read-only verbs, identify, origins, walk, variants, history, run the same way, over an infrastructure-and-threat-intelligence graph of billions of nodes. That is the enrichment that turns a per-device egress log into a detection.

The map, at a glance

Each row is a framework, the control it asks for, our verdict, the fit symbol, and the shipped evidence behind it. The deep sections below unpack each group. Read the verdict and fit columns first: they are the load-bearing part.

^¹ The HHS Cybersecurity Performance Goals are voluntary, but HHS weighs "recognised security practices" and insurers and boards increasingly demand them, a soft driver below the two hard ones (§524B and the NPRM).

FDA §524B: the refuse-to-accept gate for cyber devices

Since 1 October 2023, the FDA may refuse to accept a premarket submission (a 510(k), PMA or De Novo) for a "cyber device" that lacks the §524B cybersecurity content. That makes device product-security a hard commercial gate, and it is the sharpest budget trigger a manufacturer's PSIRT has. A "cyber device" is one that includes software, can connect to the internet, and has characteristics that could be vulnerable. §524B(b) asks a submitter to: (1) monitor, identify and address postmarket vulnerabilities with a coordinated-disclosure plan; (2) design, develop and maintain processes providing a reasonable assurance the device and related systems are secure, and make patches available; and (3) provide a machine-readable SBOM. The guidance expects a Secure Product Development Framework (SPDF): a threat model, a risk assessment, a security architecture, authentication/authorisation and cryptography, the SBOM, and a CVD process.

Two of §524B(b)'s asks map to shipped primitives; one does not, and we say so plainly:

• (b)(2) authentication & access control ◐: a device or endpoint that holds and can prove its DANE-pinned /128, and whose egress is default-deny and source-bound, is a concrete authentication-and-unauthorised-access control the security-architecture section can cite. It complements the device's own secure boot, key storage and application crypto; it never replaces them.
• (b)(1) postmarket monitoring & CVD ◐: a stable per-device identity is the join key that lets exploit telemetry be correlated to specific units across the fleet, and one-call revoke is a containment action you can demonstrate to a reviewer, not merely describe. That is substance for the postmarket plan and the coordinated-disclosure workflow.
• (b)(3) SBOM ✗: Whisper produces no software bill of materials. Full stop. Use your SBOM tooling; Whisper sits beside it.

# (b)(2): the device proves its identity to a reviewer or an HDO, keyless, to the IANA root
whisper verify --trustless 2a04:2a01:f0::b10
✓ DNSSEC chain valid to the IANA root   ✓ DANE-EE (TLSA 3 1 1) matches the device key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32   identity: VERIFIED (our API never trusted)

# (b)(1) postmarket: this unit's outbound activity, and the operator behind a suspect destination
CALL whisper.agents({op:'logs', args:{agent:'2a04:2a01:f0::b10', kind:'conn', from:'-30d'}})
curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
  --data-urlencode "q=CALL whisper.identify('<suspect destination>')"

# (b)(1) CVD containment: cut one compromised unit off worldwide, provably and timestamped
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:f0::b10'}})

HIPAA Security Rule NPRM: the CISO's forcing function

The proposed HIPAA Security Rule overhaul (published in the Federal Register on 6 January 2025; comment period closed March 2025; not final as of this writing) would remove the "required vs. addressable" distinction (making nearly every specification mandatory) and add, in rule text, a written technology asset inventory and a network map (both maintained at least annually), network segmentation, encryption at rest and in transit, multi-factor authentication, vulnerability scans at least every six months, annual penetration tests, patch management and 72-hour restoration. It converts a decade of deferred best practice into a floor. Three of its hardest asks map straight onto shipped primitives, and two do not.

The three strong fits, in the CISO's own words:

• Asset inventory ●. A maintained inventory is exactly what a per-/128, UDI-keyed identity is: every governed device and endpoint has a canonical, forge-proof, publicly verifiable network identity, not a row in a spreadsheet someone last touched a year ago. It complements (and consumes as its device_id) the inventory your IoMT visibility platform already discovers.
• Network map ●. The attribution graph plus per-/128 logs turn "map the movement of ePHI" from a diagramming exercise into a live, queryable, verifiable record of which identity talked to what.
• Network segmentation ●. Per-device egress governance is L3 segmentation enforced at the identity, default-deny by construction. Crucially, it works for the devices that break the usual approach: a device that cannot take a NAC agent, or runs an EOL OS, still gets a governed /128 egress policy (allow the EHR and the vendor cloud, block everything else) with no re-imaging and no truck-roll.

And the honest partial and out-of-scope items:

• §164.312(d) entity authentication ◐. DANE-pinned identity cryptographically authenticates the device or endpoint. That is real, and it maps to current-law entity authentication today (the NPRM does not need to be final for §164.312(a)/(b)/(d) to apply). But it is not the NPRM's multi-factor authentication, which is a human login control (see the next section).
• MFA, encryption at rest, vuln scans, pen tests ✗. Out of scope. Whisper is a network-identity primitive; these are human-factor, data-at-rest and assessment controls it does not touch.

COMPLEMENTARY: we sit alongside, we don't satisfy the cert

Several frameworks mandate the sector's own PKI, certificate or development process. Whisper does not, and must not claim to, satisfy those. It complements them: where a certificate is in play it can DANE-pin that exact certificate to DNSSEC so any relying party can verify it, and where a private community anchor is the trust root it adds a second, publicly DNS-rooted proof that anyone can check without joining the community.

• FHIR UDAP / SMART on FHIR. UDAP puts cryptographic endpoint identity on FHIR: the identifying URI is the FHIR base URL, which must match a uniformResourceIdentifier entry in the server certificate's SubjectAltName. That binding is asserted privately: you trust whichever community anchor you were configured with (a TEFCA anchor, a state-HIE anchor). Whisper publishes the very same base-URL↔certificate binding in DNSSEC + DANE TLSA, so any relying party (even outside the community, with no pre-provisioned anchor) can verify it against the DNS chain. SMART Backend Services authenticate the caller (a client JWT), not the endpoint host; Whisper is orthogonal and complementary to both. It never issues or replaces the UDAP cert.
• TEFCA / QHIN. The Common Agreement and QHIN Technical Framework bind trust through UDAP and a community CA; the RCE Directory is meant to make endpoints discoverable. Yet the ONC FAST work found "there is neither an authoritative source for digital contact information nor a consistent method for locating it." A routable /128 with a DNSSEC-signed name and reverse-DNS/RDAP makes a directory entry self-verifying: the endpoint's address is its identity, cross-checkable against the address instead of trusted blindly. Additive to the QHIN trust framework, never a replacement for it.
• HHS 405(d) HICP. The Health Industry Cybersecurity Practices, access management (Practice 3), network management (Practice 7) and medical-device security (Practice 9), are voluntary but weigh as recognised security practices. Whisper contributes concrete evidence to those practices; it does not certify against HICP.
• IEC 62443-4-2 / IEC/TR 60601-4-5. Component security requirements for industrial and health systems. Whisper provides an Identification & Authentication Control (FR1 IAC) capability at a defined security level, with egress governance mapping to FR2 (Use Control) and logging to FR6: a capability contribution a supplier can cite, not a conformance certification.
• IEC 81001-5-1 & EU MDR 17.2. These govern how health software is built: a secure development lifecycle. Whisper is a component consumed by a device, not a development process; it evidences a control, not process conformity. This is a ○ stretch, and we mark it as such.
• AAMI TIR57. The security risk-management process for a medical device. Whisper is a concrete, verifiable control a TIR57 (or ISO 14971-aligned) risk analysis can cite against spoofing and unauthorised-access threat scenarios: one mitigation in the analysis, not the analysis.
• EU MDR Annex I 17.4 + MDCG 2019-16. GSPR 17.4 requires protection against unauthorised access; identity plus egress governance is a direct control there (●). GSPR 17.2's secure-lifecycle expectation is process, not a product control (○). Either way Whisper is a control cited within the technical documentation, never a CE conformity route.

DO-NOT-CLAIM: what we will not say

The most useful rows on a compliance page are the ones a vendor omits. These exist, they matter, and Whisper is honestly the wrong tool for them. We list them so nobody plans against an over-claim:

• Not MFA or user authentication. Multi-factor authentication in the HIPAA NPRM is a human login control. Whisper authenticates a device or endpoint (§164.312(d) entity authentication). Mapping our identity to "MFA" is a category error, and we will not make it. ○
• Not a §524B or MDR clearance / conformity route. Whisper is a control and a body of evidence inside a submission or technical file; it never clears a device, passes an RTA, or grants a CE mark. A reviewer or a notified body does that. ✗
• No SBOM, no encryption at rest. §524B(b)(3)'s machine-readable SBOM and the NPRM's data-at-rest encryption are outside a network-identity primitive entirely. Use your SBOM and encryption tooling; Whisper sits beside them. ✗
• No vulnerability scanning or penetration testing. The NPRM's 6-month scans and annual pen-tests are assessment activities Whisper neither performs nor replaces. ✗
• The HIPAA NPRM is not final. We map to it as directional guidance and anchor the load-bearing claims in current law. No claim on this page depends on the proposal being finalised.
• NERC CIP and other-sector regimes are out of scope here. A Whisper /128 is useful across sectors, but the bulk-electric-system and non-health frameworks belong on their own vertical pages, not this one. ✗

Caveats we state up front

Buyer trust is built by naming the limits before the sales call does:

• DANE/DNSSEC is operator-chosen defence-in-depth, strongest at the trust boundaries. Whisper's value concentrates where organisations and trust domains meet: device onboarding and the DNS/PKI that anchors it, HIE/TEFCA cross-organisation exchange, and any FHIR/API endpoint exposed to the internet. It is a layer you choose to add on top of your existing anchors, not a mandate and not a rip-and-replace.
• Revocation is at the identity/network layer, not the credential/cert layer. One revoke tears down the /128, its PTR and its DANE pin worldwide at DNS-TTL: an additional, orthogonal kill-switch. It does not revoke the device's UDAP certificate or its OEM-issued leaf; those keep their own CRL/OCSP lifecycle. The point is that you gain a second off-switch that works publicly and immediately, across organisations, without waiting on a community CA.
• Identity is only as forge-proof as key custody. The /128 is derived from the device's key; on an EOL device with weak key storage and no TPM or secure element, the identity inherits that weakness. State it plainly: Whisper hardens the network trust and reachability of a device, it does not retrofit a hardware root of trust one never had.
• It is an identity / attribution / reachability control: complementary to segmentation, device patching and protocol-level auth of legacy clinical traffic. It kills stolen-static-credential and hard-coded-key reuse, shrinks token-replay and rogue-aggregator exposure, and constrains who a device can reach. It does not stop purely-internal, unauthenticated-protocol manipulation between two nodes on the same segment (an HL7v2 injection or an unauthenticated DICOM C-STORE, a segmentation and protocol-auth problem), an insider abusing a valid session, ransomware already executing locally, or the unpatchable CVE itself.

Nothing issued in the dark: the transparency-log audit trail

Every identity mint and every revocation lands in a public, append-only Merkle transparency log (RFC 6962 tlog-tiles), with Ed25519-signed C2SP checkpoints, each root anchored to Bitcoin via OpenTimestamps. That gives a regulated HDO or manufacturer something a database row cannot: a non-repudiable answer to "when was this device or vendor's access granted, and when was it removed", provably not back-dated, provably in order. For an FDA postmarket file, an OCR inquiry, or a TEFCA accountability question, that is the difference between an assertion and evidence.

# An identity's ordered lifecycle (issuance, any rotations, revocation), keyless
curl -s https://whisper.online/ip/2a04:2a01:f0::fda/transparency | jq

# The signed log checkpoint + its Bitcoin anchor: the tamper-evidence root
curl -s https://whisper.online/checkpoint
# -> a C2SP signed note; the root is OpenTimestamps-anchored to Bitcoin

Evidence you can hand an auditor, OCR, or an FDA reviewer

The point of every primitive above is that the reviewer does not have to trust Whisper. Each artifact is reproducible from the internet's own records with stock tools: the same --trustless walk any resolver could run. A per-control evidence bundle for an OCR risk-analysis review, a §524B postmarket file, or a TEFCA accountability request looks like this, and every line is checkable without an account:

# IDENTITY (§164.312(d) / §524B(b)(2)): the identity is genuine and current, verified to the IANA root
whisper verify --trustless 2a04:2a01:f0::fda
✓ DNSSEC chain valid to the IANA root   ✓ DANE-EE (TLSA 3 1 1) matches the key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32   identity: VERIFIED (our API never trusted)

# INVENTORY + MAP (HIPAA NPRM / §164.312(b)): the governed identities and their egress record
CALL whisper.agents({op:'list',    args:{kind:'agent'}})
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:f0::fda', kind:'conn', from:'-30d'}})

# RECON TRIPWIRE (§164.312(b) audit): who enumerated this endpoint, across organisations
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:f0::fda', window:'30d'}})

# SEGMENTATION (HIPAA NPRM): a default-deny egress policy for one device, even an agentless / EOL one
CALL whisper.agents({op:'firewall', args:{agent:'2a04:2a01:f0::b10',
  default:'deny', allow:['ehr.example-hdo.org', 'updates.vendor.example']}})

# CONTAIN + NON-REPUDIATION (§524B(b)(1) / §164.312): the offboarding, provable and timestamped
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:f0::b10'}})
curl -s https://whisper.online/ip/2a04:2a01:f0::b10/transparency   # the timestamped lifecycle leaf

And because device telemetry (or a DICOM object's provenance) can be bound to and signed under the device's forge-proof /128, an HIE, a registry, and your own quality system can trust the data came from the real device, which is the non-repudiation those audit families ultimately want. Egress governance rounds out the control surface: op:firewall to allow/deny by host, CIDR or port, op:budget to cap a device's traffic, op:policy for graph-first default-deny resolution, and op:revoke to kill it worldwide (the "control plane," not just "identity.")

SIEM & threat-intel export

The evidence above is pullable now via op:logs, op:lookups and the graph API, and it exports to Splunk today as signed, replayable JSON mapped to CEF / ECS fields. Broader connectors are on the roadmap, labelled honestly so nobody plans against vapour:

Until the roadmap items land, the same records are already reachable: the exports are a convenience layer over evidence you can pull today.

What this is, and is not

Whisper anchors one boundary: the cloud/IP interface between a device (or a FHIR-API consumer) and the backend, and the endpoint-to-endpoint boundary between organisations. It is deliberate about what it does not touch.

• It is not your CSMS, your IoMT visibility platform, your SBOM, or your EHR's authorisation server: it is the identity-and-attribution layer those systems consume. It complements them; it does not replace them. It plugs alongside Claroty / Armis / Ordr / Forescout / Palo Alto and consumes their UDI / inventory as the device_id.
• It does not sit inside the HL7v2 or unauthenticated-DICOM message on a flat LAN, the device's own secure boot or application crypto, or a clinician's login flow. Those keep their own controls; a Whisper DANE-anchored identity complements them at the network layer without cross-signing.
• These platform mappings are proposed, not vendor-endorsed, and no HDO, vendor or clearinghouse is named as a breach victim: the exposure classes referenced on this page are drawn from public research and advisories at the class level only.

Everything described as working is checkable, today, with dig, curl and one control-plane call. Everything on the roadmap is labelled as such. That is the whole contract of this page.

Next

• Device & FHIR-endpoint identity: how the device-derived /128 is computed from the key a device or endpoint already holds, and why Endpoint.identifier / UDI is the natural domain separator.
• Device/API-abuse cure: the same identity, applied to the stolen-token / BOLA problem at the FHIR-API ingress.
• Verify · attribute · govern: runnable recipes that generate exactly the artifacts this page maps to a control.