# 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. > **How to read this page.** We grade every control into one of three verdicts and never blur them. **DIRECT-ADDITIVE**: Whisper produces evidence that maps to the control (one input to your package, never the whole standard). **COMPLEMENTARY**: the framework mandates the sector's own PKI, certificate or process; Whisper sits alongside it and can DANE-pin it, but does *not* satisfy that requirement. **DO-NOT-CLAIM**: controls Whisper is honestly the wrong tool for; we list them so nobody over-claims. Each row also carries a fit symbol: ● strong · ◐ partial · ○ stretch · ✗ not-addressed. ## 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: - **DIRECT-ADDITIVE ●.** Whisper produces the evidence, as one input to your package: §524B(b)(1)/(2) · UDI traceability · HIPAA NPRM asset inventory, network map, segmentation · §164.312(a)/(b)/(d). - **COMPLEMENTARY ◐.** It sits alongside, DANE-pins the cert, and never satisfies it: UDAP / SMART · TEFCA / QHIN · 405(d) HICP · IEC 81001-5-1 · IEC 62443-4-2 · AAMI TIR57 · EU MDR / MDCG 2019-16. - **DO-NOT-CLAIM ✗ / ○.** Controls Whisper is honestly the wrong tool for: MFA · the §524B(b)(3) SBOM · encryption at rest · a §524B/MDR clearance route · other-sector regimes. The honesty rule is the whole point of this page: a network primitive earns a verdict per control, and we mark `DIRECT-ADDITIVE`, `COMPLEMENTARY` or `DO-NOT-CLAIM` (plus a ●/◐/○/✗ fit), so a buyer, an auditor, an OCR investigator and an FDA reviewer all read the same thing. ## 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`. > **Shipped & live.** The device-derived `/128`, per-`/128` logs, `op:lookups`, one-call `revoke`, the Merkle transparency log and the attribution graph are in production. The **Splunk**, **Microsoft Sentinel** and **OpenCTI** connectors ship. Everything grouped under *roadmap* below (STIX/TAXII, a first-class `--udi` flag) is labelled as such; nothing on this page is described as working unless you can reproduce it. ### 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:'', 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. ``` > `https://fhir.example-hdo.org/r4` is a placeholder FHIR base URL and `00819320012345` below is a placeholder GS1 UDI Device Identifier; no real device, endpoint or manufacturer is implied. The `device_id` argument is generic: pass a FHIR `Endpoint.identifier`, an FDA `UDI`, a DICOM AE-Title, or an `EUI-64`. A first-class `--udi` CLI flag is **on the roadmap**; provision via the control-plane call above today, which **is** live. *(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 lands on the wire natively.)* ### 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. | Framework · control | What it asks for | Verdict | Fit | Whisper evidence (shipped) | |---|---|---|---|---| | **FDA §524B(b)(2)**: design controls | Reasonable assurance the device & systems are secure: authentication & access control | DIRECT-ADDITIVE | ◐ | DANE-pinned identity + source-bound egress governance: one control inside the SPDF | | **FDA §524B(b)(1)**: postmarket + CVD | Monitor, identify & address postmarket vulnerabilities; a coordinated-disclosure plan | DIRECT-ADDITIVE | ◐ | Stable per-device `/128` to correlate exploit telemetry · one-call `revoke` for containment you can demonstrate | | **FDA cyber-device UDI** traceability | A device identity keyed to the UDI in labeling & GUDID, aligned with recall | DIRECT-ADDITIVE | ● | Identity keyed to the `UDI` as `device_id`: identity, traceability & recall on one anchor | | **FDA §524B(b)(3)**: SBOM | A machine-readable software bill of materials | DO-NOT-CLAIM | ✗ | Not provided: Whisper is not an SBOM tool | | **HIPAA NPRM**: technology asset inventory | A written, maintained inventory of technology assets (proposed, ≥ annual) | DIRECT-ADDITIVE | ● | Per-`/128`, UDI-keyed identity = a canonical, forge-proof inventory anchor | | **HIPAA NPRM**: network map | A map of the movement of ePHI through the network (proposed, ≥ annual) | DIRECT-ADDITIVE | ● | The attribution graph + per-`/128` logs = a live, verifiable network map, not a stale spreadsheet | | **HIPAA NPRM**: network segmentation | Segment the network to limit lateral movement (proposed) | DIRECT-ADDITIVE | ● | Per-device egress governance = an L3 default-deny allow-list, even for agentless / EOL devices | | **HIPAA §164.312(d)**: entity authentication | Verify a person or entity seeking access is the one claimed | DIRECT-ADDITIVE | ◐ | DANE-pinned identity cryptographically authenticates the *device/endpoint*: additive, **not** human MFA | | **HIPAA §164.312(b)**: audit controls | Record & examine activity in systems containing ePHI | DIRECT-ADDITIVE | ● | Per-`/128` logs + `op:lookups` + signed graph evidence = an egress audit trail | | **HIPAA NPRM**: MFA | Multi-factor authentication for access (proposed) | DO-NOT-CLAIM | ○ | MFA is a *human* login factor; Whisper does entity/device auth (§164.312(d)), not MFA | | **HIPAA NPRM**: encryption at rest / vuln-scan / pen-test | ePHI encryption at rest, 6-month scans, annual pen-tests | DO-NOT-CLAIM | ✗ | Out of scope: a network-identity primitive touches none of these | | **HHS CPGs (2024)**: asset inventory + segmentation | Enhanced goals: maintained asset inventory; network segmentation | DIRECT-ADDITIVE ¹ | ● | The same inventory anchor + egress governance: recognised-security-practice evidence | | **UDAP / SMART** endpoint trust (X.509) | Cryptographic endpoint/app identity via a community-CA cert chain | COMPLEMENTARY | ◐ | A second, DNS-rooted DANE proof keyed to `Endpoint.identifier`: never replaces the cert chain | | **TEFCA / QHIN** identity proofing | Strong identity proofing & authentication across the exchange | COMPLEMENTARY | ◐ | DNS-anchored endpoint identity + cross-org attribution: sits alongside the QHIN trust framework | | **HHS 405(d) HICP**: Practices 3/7/9 | Access / network / asset mgmt + medical-device security (voluntary) | COMPLEMENTARY | ◐ | Contributes to the access/network/asset-management and device-security practices; does not certify them | | **IEC 62443-4-2** / TR 60601-4-5 | Component security requirements (FR1 IAC, FR2 UC, FR6) | COMPLEMENTARY | ● | Provides an IAC capability (FR1) at a defined SL-C; egress → FR2; logs → FR6: a capability, not a certification | | **IEC 81001-5-1**: secure lifecycle | How health-software is *built* (secure development process) | COMPLEMENTARY | ○ | Whisper is a component, not a development process: evidences a control, not process conformity | | **AAMI TIR57**: device security risk | A security risk-management process for a device | COMPLEMENTARY | ◐ | A concrete, verifiable control a TIR57 risk analysis can cite against spoofing / unauthorised-access threats | | **EU MDR** Annex I 17.4 / MDCG 2019-16 | Protection against unauthorised access (17.4); secure lifecycle (17.2) | COMPLEMENTARY | ◐ | Identity + egress governance is a 17.4 control (●); 17.2 lifecycle is process, not a product control (○): never a conformity route | | **A §524B or MDR** clearance / conformity route | Market authorisation or a CE conformity decision | DO-NOT-CLAIM | ✗ | Whisper is a control + evidence *within* a submission: never a clearance shortcut | | **NERC CIP / other-sector** scope | Bulk-electric-system & non-health regulatory regimes | DO-NOT-CLAIM | ✗ | Not in scope on a health page: see the energy vertical for the CIP map | ¹ 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. > **What Whisper is here, and is not.** Whisper is a *feature you can point to* in the security-architecture and postmarket sections of an SPDF, plus reproducible *evidence* for it. It is emphatically **not** a §524B clearance, an RTA-pass guarantee, or a substitute for the threat model, the SBOM, secure boot, or the device's own cryptography. A reviewer clears the submission; Whisper strengthens two of the boxes inside it. 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. §524B(b)(1)/(2) is a monitor-then-contain loop; Whisper ships each step as an artifact keyed to the device's `UDI`, and the transparency log turns the loop into a record a reviewer can replay, without ever being, or pretending to be, the clearance itself. The loop, as shipped: a **device `/128`** (DANE-EE · RDAP · UDI) answers *which device this is* (§524B(b)(2)); **per-`/128` logs + the attribution graph** monitor and identify postmarket telemetry (§524B(b)(1)); **`op:revoke`** contains one unit worldwide at DNS-TTL (the CVD containment step); and the **Merkle transparency log + keyless verify** make the whole loop a non-repudiable record for the submission, *not a clearance*. ``` # (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('')" # (b)(1) CVD containment: cut one compromised unit off worldwide, provably and timestamped CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:f0::b10'}}) ``` > `2a04:2a01:f0::b10` is a placeholder device `/128`, here a biomed unit provisioned with `device_id: 00819320012345` (a placeholder GS1 UDI Device Identifier). Nothing here reveals the device's location: reverse-DNS and RDAP return the registry object, and `dig -x` resolves a hashed name like `dev-3f2504e0.example-hdo.whisper.online`, never the raw UDI or a whereabouts. ## 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. Against the NPRM, Whisper is honest to a fault: inventory, network map and segmentation are ● strong fits; §164.312(d) entity authentication is ◐ partial and explicitly *not* the NPRM's human MFA; encryption at rest, MFA, scanning and pen-testing are ✗ squarely out of scope. 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. > **The NPRM is a proposal, not a rule.** Sell it as directional certainty ("this is where the floor is going") and anchor the hard evidence in *current* law: §164.312(a) access control, §164.312(b) audit controls, §164.312(d) entity authentication, §164.312(e) transmission security, and the §164.308 risk analysis. Everything on this page that maps to the NPRM also has a current-law hook, so nothing here depends on the proposal being finalised. ## 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. > Why this whole group is COMPLEMENTARY and not DIRECT: each of these frameworks roots trust in a *closed* place, a private community CA (UDAP/TEFCA), an OEM's private PKI, or a development-process audit. Whisper's contribution is to take the identity those systems already assert and anchor it in *open* DNS/DANE, so it becomes publicly verifiable and revocable at DNS-TTL by any relying party. It upgrades the anchor; it is not the mandated cert or process. ## 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](/docs/transparency) (RFC 6962 `tlog-tiles`), with Ed25519-signed C2SP checkpoints, each root anchored to Bitcoin via [OpenTimestamps](/docs/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 ``` > **Honest status.** The log is tamper-evident, Ed25519-signed and Bitcoin-anchored *today*, but it is **not yet independently witnessed** (our two authoritative nodes co-signing is availability, not independence). It already speaks the C2SP `tlog-witness` protocol, so an external witness can co-sign; until one does, treat the guarantee as tamper-*evident*, not third-party-attested. It is also GDPR/HIPAA-friendly by construction: leaves are salted opaque commitments with selective disclosure, so erasing the salt (an `op:erase`) renders a leaf's meaning unrecoverable while the proofs stay valid. ## 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](/docs/sign-outputs) 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: | Destination | Status | |---|---| | Splunk (signed JSON → CEF / ECS) | **Shipped** | | Microsoft Sentinel connector | **Shipped** | | OpenCTI | **Shipped** | | STIX 2.1 / TAXII feed | Roadmap | | Health-ISAC machine-readable JSON export | Roadmap | 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](/docs/device-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](/docs/device-api-abuse-cure): the same identity, applied to the stolen-token / BOLA problem at the FHIR-API ingress. - [Verify · attribute · govern](/docs/health-recipes): runnable recipes that generate exactly the artifacts this page maps to a control.