# The FDA can refuse the submission. OCR wants a network map you don't have. And the device still can't prove who it is.

FDA §524B can refuse-to-accept a cyber-device premarket submission that lacks identity and monitoring evidence. The HIPAA Security Rule NPRM proposes to make a maintained asset inventory, a network map, network segmentation and entity authentication mandatory. Both turn on one primitive tens of thousands of your networked machines were never built to have: an identity they can prove. They present a claim — a token, a shared credential, a same-VLAN IP — not machine-bound proof. So a stolen secret is the device, and your inventory is a spreadsheet.

**We give the device one.** Bind the identifier it already carries — a FHIR Endpoint.identifier, an FDA UDI — to a routable, DNSSEC-anchored /128 you can inventory, attribute, micro-segment, and revoke worldwide in a single call — additive, out-of-band, zero device firmware change. The inventory, the map, and the entity-auth evidence write themselves.

`whisper verify --trustless` — anchored at the IANA DNS root. Our own API is not in the trust path.

- **§524B** — since Oct 2023 the FDA can refuse-to-accept a cyber-device submission with no identity + monitoring plan.
- **HIPAA NPRM** — proposes a mandatory asset inventory, network map, segmentation & entity authentication.
- **~60%** of health systems say they can't protect unpatchable / agentless devices — their biggest self-identified gap (HIMSS).
- **53%** of connected medical / IoT devices carry a known critical vulnerability (Cynerio, 300+ hospitals).
- **+35–41%** in-hospital mortality for patients already admitted when ransomware hits (U Minnesota, Medicare claims).
- **DNS-TTL** — one compromised device or burned endpoint, revoked worldwide, in a single call.

## Four buyers across the health chain. One missing primitive between all of them.

The health system that has to pass an OCR audit, the device maker that has to clear an FDA submission, the HIE moving records under TEFCA, and the telehealth platform standing up endpoints all face the same structural gap: the device or endpoint has an identity it cannot prove off its own ecosystem, and no one outside can revoke.

### A · HDO security & biomed / HTM lead

*Trigger: HIPAA-NPRM inventory + segmentation · a ransomware event · a Joint Commission cycle.*

**"Turn your IoMT inventory into a verifiable, revocable identity register — and micro-segment at the device, not the VLAN."** Give each device a forge-proof /128 keyed to its UDI: a canonical inventory anchor and a live network map, not a spreadsheet. Enforce a default-deny egress allow-list at the device — even one that can't take a NAC agent. Attribution you can hand OCR when it asks "what talked to ePHI, prove it." Contain a compromise in one `revoke` — no re-imaging, no truck-roll, zero device firmware change.

*Vocab: IoMT · unmanaged / agentless · MDS2 · CMMS · VLAN / micro-seg · ePHI · OCR · zero-trust · "can't put an agent on it."*

### B · Medical-device maker PSIRT / regulatory

*Trigger: the §524B RTA gate on the next submission · a postmarket CVE needing containment · EU MDR + IEC 81001-5-1.*

**"Ship §524B identity + monitoring evidence in the box — and publish a device identity your customers can actually verify."** A hardware-key-derived, DANE-pinned identifier a reviewer verifies externally against the DNS root — one authentication/access control to cite in your SPDF security architecture, and a stable per-device ID plus one-call revocation to demonstrate postmarket containment for your CVD plan. Additive to your SPDF + SBOM: you still own the SBOM, the patching cadence, and the postmarket plan.

*Vocab: §524B · RTA · SPDF / SDL · threat model · SBOM · CVD · UDI / GUDID · IEC 81001-5-1 · AAMI TIR57 · MDCG 2019-16.*

### C · HIE / QHIN / TEFCA participant security

*Trigger: TEFCA onboarding · endpoint spoofing · UDAP registration friction · "prove this endpoint is who it says."*

**"A public trust anchor for the endpoint identity UDAP asserts privately."** DANE-pin the very base-URL↔certificate binding UDAP asserts inside a community CA, so any relying party — even outside your trust community, with no pre-provisioned anchor — verifies it against the open DNS chain, and revokes at DNS-TTL. Cross-organization attribution of which endpoints connected, for TEFCA accountability. Keyless verification for everyone; the control plane for key-holders. Additive to UDAP / SMART / TEFCA — never a replacement.

*Vocab: FHIR · Endpoint resource · UDAP · SMART · tiered OAuth · mTLS · TEFCA / QHIN · DirectTrust · RCE directory · IAL2 / AAL2.*

### D · Telehealth / digital-health platform security

*Trigger: scaling RPM endpoints · a rogue-integration incident · a partner's endpoint-trust requirement.*

**"Per-endpoint verifiable identity + egress governance — without standing up a private CA."** One call to provision each endpoint or connected device a routable, DANE-pinned /128 from its own key, one call to revoke; a default-deny egress policy per endpoint; and a per-/128 audit trail your partners and your assessor can both use. No enrollment portal, no CRL to run — the identity is anchored in DNS you already publish. (NIST SP 1800-30 identity management, applied at the network layer.)

*Vocab: RPM · per-endpoint identity · API integration · egress governance · NIST SP 1800-30 · BAA · audit trail · SMART Backend Services.*

Different words, one primitive underneath all four: **the address is the device.** A device or endpoint identity that is publicly verifiable, addressable, and revocable at DNS-TTL — the three properties every anchor the sector runs today keeps trapped in a closed place (an appliance inventory, an OEM's private PKI, a community CA).

## Strip the incident down and it isn't a hundred bugs. It's two.

The pattern is old: land on a flat, converged segment, harvest a static credential (a hard-coded key, a long-lived token — with no machine identity, a stolen secret is the device), exfiltrate via a FHIR BOLA or an unauthenticated DICOM read, rotate the egress, and reuse the loot against the next organization. It leans on exactly two structural gaps that every health program shares.

### Gap 1 · you can't follow them across organizations when the IP rotates

Rate-limit an IP and they spin up a fresh one. The egress is disposable; the last IP was never the attacker. And your IoMT visibility console — excellent as it is — has vantage only inside your own edge: when a rogue aggregator or a burned credential phones home from someone else's network, the cross-organization view simply isn't there. Roughly 41% of 2024 healthcare breaches originated with a third-party, which is exactly where that blind spot lives.

**The answer — the graph.** A live internet-infrastructure graph — 7.44B nodes and 39.3B relationships of fused BGP, DNS, WHOIS, TLS, hosting and threat intelligence, answering in under 300 ms — fingerprints the operator, not the IP. Two levers, kept honestly separate: for cloud rotation it clusters shared ASN, hosting and certificate lineage into one infrastructure genealogy; for a residential-proxy swarm — where a subscriber IP gives an infra graph nothing to grab — a `JA4/JA3` client fingerprint travels with the tooling, invisible to the proxy because it lives in the TLS handshake, and collapses the swarm to one operator. Because the graph is cross-organization, it sees the operator your single-site console structurally can't. Every answer returns a reproducible evidence chain your SOC, your auditors and OCR can replay.

> *"When a compromised device or a rogue aggregator exfiltrates through rotating cloud and residential IPs — across organizations — can you actually attribute it, or just block an IP and move on?"*
>
> **Attribute it.** Infrastructure genealogy collapses the cloud rotation; a JA4 client fingerprint collapses the residential swarm; and because the graph spans organizations, it sees the operator a single hospital's console can't. The egress IP is the one thing we don't rely on, and the finding lands as a reproducible, replayable evidence chain, ready for the OCR file, not a hunch.

### Gap 2 · a stolen credential is indistinguishable from the device

A controller, an EHR, a FHIR server authenticates a claim — a bearer token, a shared credential, a static key, a same-VLAN IP — not the machine. So a hard-coded key or a long-lived token is the device to whoever holds it. And there's no cross-organization off-switch: a credential burned at org A is happily reusable against org B, because nothing at the network layer can turn a stolen identity off everywhere at once.

**The answer — identity.** Bind the device or endpoint to its own forge-proof /128 — an address derived from the key it already holds and named by the identifier it already carries (the FHIR Endpoint.identifier, the FDA UDI). A stolen static credential with no key behind it authenticates to nothing. And when a unit or an endpoint goes bad, one `revoke` drops its /128, PTR and DANE pin worldwide at DNS-TTL — the cross-organization off-switch the community CA's CRL/OCSP never gave you.

> *"UDAP already gives our FHIR endpoints X.509 identity. Why isn't that enough?"*
>
> **Because it's anchored in a private community CA, and a relying party outside that community can't verify it.** UDAP's own rule is elegant — the identifying URI equals the FHIR base URL and must match a `uniformResourceIdentifier` SAN in the server's certificate. But nothing anchors that binding in DNS, and revocation is in-community CRL/OCSP. Whisper keeps the exact base-URL↔cert binding UDAP asserts and re-publishes it with DANE under DNSSEC, so any relying party verifies it against the IANA root with no pre-provisioned anchor — and one revoke drops it at DNS-TTL. It complements UDAP; it never replaces it.

Gap 1 makes detection durable enough to attribute across organizations. Gap 2 gives the device an identity a stolen secret can't fake. Together they break exactly the links — harvest, exfiltrate, reuse cross-org — the health kill chain is built on.

## Three planes on one primitive — and all three exit into the stack you already run.

The primitive is one line: **the address is the identity** — a routable IPv6 /128 out of `2a04:2a01::/32` (announced by AS219419), DNSSEC-anchored, DANE-EE pinned, verifiable by anyone with `dig`. Point it at your devices and endpoints and you get three planes, no new silo, and no re-flashing the fielded fleet.

- **Identity.** Each device's or endpoint's /128 is derived from the key it already holds — a TPM or secure element, the key behind a FHIR endpoint's certificate — and named by the identifier it already carries: the FHIR Endpoint.identifier or the FDA UDI as the domain separator. The private key never leaves the device. The backend authorizes on the pinned identity, not a stealable token. *Who is this, provably.*
- **Attribution graph.** The operator fingerprint across rotating clouds and residential proxies — infrastructure genealogy plus JA4/JA3 — across organizations, with a reproducible evidence chain on every answer. *Who's really behind this connection, when the IP rotates and it isn't on your network.*
- **Egress governance.** Per-device /128, default-deny policy, an `op:lookups` reconnaissance tripwire, `op:firewall` allow/deny, `op:budget` caps, and one `op:revoke` kill-switch. *What each device may talk to — an L3 allow-list at the device — and the off-switch when it goes bad.*

The identifier a device already carries — a UDI, a FHIR Endpoint.identifier — becomes a routable, publicly verifiable /128 keyed to the device's own key: `device key + identifier → /128 → a name anyone can verify (whisper verify --trustless) → op:revoke → gone worldwide at DNS-TTL`. The binding UDAP asserts inside a community CA becomes one any relying party can check against the DNS root, and revoke at DNS-TTL.

**Additive to what you already run — it does not replace it.** Whisper complements the anchors the sector already trusts — UDAP and SMART-on-FHIR endpoint trust, a maker's build-time device PKI, the FDA UDI in GUDID, TLS on the clinical protocols (DICOM PS3.15, IHE ATNA), TPM/HSM/secure elements. It is the publicly verifiable, DNSSEC/DANE-anchored layer on top, anchoring the device↔network boundary at the IP/DNS/transport layer — it never sits inside the HL7v2 or DICOM wire, and never touches the UDAP community handshake. No bespoke CA trust store to push to every device, and revocation at DNS-TTL speed instead of an in-community CRL/OCSP. You can even DANE-pin your existing FHIR endpoint's certificate to DNSSEC and cut single-community-anchor trust risk. One key per identity, never a shared root — compromise one device and you've compromised that device, not the fleet.

## The honest compliance map — mapped where it's defensible, explicit where it isn't.

A compliance claim you can't defend in front of an assessor is worse than none. Fit: ● strong · ◐ partial.

### Direct-additive — Whisper produces the evidence artifact

| Standard & clause | What it requires | How Whisper is direct-additive evidence | Fit | Artifact |
|---|---|---|---|---|
| HIPAA Security Rule NPRM — maintained technology asset inventory | A written, maintained inventory of technology assets (≥ annual) | A per-/128 identity register keyed to each device's UDI / endpoint identifier — a canonical, forge-proof inventory anchor | ● | Identity register |
| HIPAA Security Rule NPRM — network map | A map of how ePHI moves across the network (≥ annual) | The attribution graph renders a live, verifiable map of what each identity actually talks to — not a stale diagram | ● | Attribution graph · per-/128 logs |
| HIPAA Security Rule NPRM — network segmentation | Segment the network to limit lateral movement | Per-device default-deny egress governance — an L3 allow-list enforcement point at the device, complementing your VLAN / NAC | ● | Policy · firewall log |
| HIPAA §164.312(d) — person-or-entity authentication (current law) | Verify a person or entity seeking access is the one claimed | A DANE-pinned identity cryptographically authenticates the device / endpoint as an entity (not human MFA) | ● | Verify transcript · DANE pin |
| HIPAA §164.312(b) — audit controls (current law) | Record & examine activity in systems with ePHI | Per-/128 activity logs + attribution = a per-device egress audit trail | ● | Per-/128 logs |
| FDA §524B(b)(2) — cybersecurity in the SPDF | Reasonable assurance the device & related systems are secure (authn / access) | A DANE-pinned device identity + egress governance = one authentication / access-control control to cite in the security architecture | ◐ | SPDF security-architecture reference |
| FDA §524B(b)(1) — postmarket monitoring + CVD | Monitor, identify & address postmarket vulnerabilities; a CVD plan | A stable per-device identity to correlate exploit telemetry + one-call containment (revoke a unit) | ◐ | Transparency-log lifecycle · revoke log |
| FDA cyber-device UDI traceability | Devices identified & traceable via UDI / GUDID | Identity keyed to the UDI DI — identity, traceability & recall aligned on one anchor | ● | Identity register keyed to UDI |
| HHS HPH CPGs (2024) — Asset Inventory + Network Segmentation | Recognized security practices HHS weighs | Directly supports the asset-inventory & segmentation CPGs (and 405(d) HICP Practice 9, medical-device security) | ● | Identity register · policy log |
| EU MDR Annex I §17.4 — protection against unauthorised access | Devices designed to protect against unauthorised access | An identity + egress-governance control evidencing the network-access requirement | ● | Verify transcript · policy log |
| IEC 62443-4-2 FR1 (IAC) · NIST SP 800-66r2 | Identification & authentication control; HIPAA→CSF/800-53 mapping | A key-derived /128 provides an IAC capability at a defined level; per-/128 logs feed FR6; speaks the assessor's control language | ◐ | Verify transcript · control-mapping reference |

### Complementary — Whisper sits alongside & can DANE-pin it, never replaces it

| Standard / anchor | What it is | How Whisper complements it |
|---|---|---|
| UDAP (HL7 SSRAA / FAST Security IG) | X.509 endpoint trust via a private community CA | We DANE-pin the base-URL↔cert binding UDAP asserts — publicly verifiable by any relying party, revocable at DNS-TTL |
| SMART on FHIR / OAuth2 | App-to-server authorization | Authenticates the caller; we anchor the endpoint — orthogonal, additive, never replaced |
| TEFCA / QHIN / RCE Directory | National FHIR endpoint discovery | A self-verifying /128 makes a directory entry cross-checkable against the address itself, not trusted blindly |
| FDA UDI / GUDID | A regulator device registry — a name, not a wire identity | Bind `device_id` = UDI to a routable, forge-proof /128; for devices that can't present a UDI on the wire, your IoMT inventory is the join |
| IEC 62443-4-2 / 81001-5-1 / an OEM device PKI | Build-time cryptographic identity, in the maker's private trust domain | Publicly anchor a maker-issued leaf in open DNS/DANE — the operating HDO or HIE can verify & revoke it |
| DICOM TLS (PS3.15) / IHE ATNA / HL7 protocols | The device's own protocol-layer security | We anchor the device↔network boundary at IP/DNS/transport — we never touch the clinical protocol on the wire |

### What Whisper does NOT claim

This is a network-identity, attribution and reachability control — one control, honestly scoped. It is **not MFA** or human user authentication (we authenticate the device / endpoint entity under §164.312(d), not a clinician's login). It is **not a §524B refuse-to-accept clearance or an EU MDR conformity route** — a device evidences a control inside your SPDF, it doesn't clear it, and IEC 81001-5-1 / MDR §17.2 are about how you build software, a process this product doesn't conform to. It does **not** provide a machine-readable SBOM (§524B(b)(3)), encryption at rest, vulnerability scanning, penetration testing, secure boot, or the device's own cryptography. And it **never replaces UDAP, SMART or OAuth** — it's a complementary, DNS-rooted second proof of the same identity. Anyone selling you "§524B in a box" or "HIPAA compliance in a box" is selling you a binder, not a control.

### Where this control actually reaches — and where it stops

It governs network trust, reachability and egress, so it breaks the stolen-static-credential, rogue-endpoint and cross-org-reuse links in the kill chain and chokes C2 / exfil. It does **not** stop purely-internal, unauthenticated-protocol manipulation between two devices on the same segment (an HL7v2 injection or an unauthenticated DICOM C-STORE is a segmentation + protocol-auth problem); it does **not** patch the unpatchable CVE (URGENT-11 / Ripple20 stays exploitable on-path — we reduce who can reach it and attribute the reach); and an identity is only as forge-proof as the device's key custody — weak on EOL devices with no TPM/secure element, and we say so. The **HIPAA Security Rule NPRM is not final** (comments closed March 2025) — treat the inventory / map / segmentation mapping as where the floor is heading; the load-bearing current-law hooks are §164.312(a)/(b)/(d)/(e) and the §164.308 risk analysis. And the revocation here is a network / identity kill-switch at DNS-TTL — an additional off-switch, not a replacement for your credential-revocation (CRL/OCSP) process.

```
# NETWORK MAP / AUDIT — who has been querying this device's identity?
$ export WHISPER_API_KEY=whisper_live_xxx
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" \
    --data-urlencode "q=CALL whisper.agents({op:'lookups', args:{addr:'2a04:2a01:d1c::5e'}})"
  → 4 resolvers · 1 RDAP access in the window
  → source fingerprinted: 37 exit IPs (AWS/GCP/Azure + residential) → 1 operator

# CONTAIN — cut a compromised device or a burned endpoint off, worldwide, in one call
$ whisper kill --revoke 2a04:2a01:d1c::5e
  ✓ /128 · PTR · DANE pin torn down — gone at DNS-TTL
  ✓ written to the transparency log (Ed25519-signed, OTS-anchored)
  → OCR-ready: inventory entry + attribution + containment, timestamped & replayable
```

Every capability lands on a clause and produces an artifact you can file — not a dashboard you screenshot. [See the full mapping in the docs →](/docs/health-compliance)

## Nothing is issued — or revoked — in the dark.

For a regulated device program — an FDA CVD, a HIPAA audit, an EU MDR post-market file — "we revoked it" is a claim; "here is the signed, timestamped, append-only proof that we revoked it" is evidence. Every identity mint and every revocation lands in a public log built for exactly that.

- **Append-only, signed, Bitcoin-anchored.** Every mint and every `revoke` is a leaf in a public, append-only RFC 6962 Merkle log (`tlog-tiles`), with C2SP signed-note checkpoints (Ed25519) and each root anchored to Bitcoin via OpenTimestamps. Endpoints `/checkpoint`, `/checkpoint/key` and `/ledger` are public — your auditor reads them without asking us.
- **The honest status.** It is tamper-evident today — signed and Bitcoin-anchored — but not yet independently witnessed; our two servers co-signing is availability, not independence. The log speaks C2SP `tlog-witness`, so any external witness can co-sign, and that is the next step. We state this plainly rather than overclaim it.
- **HIPAA / GDPR-compatible by construction.** Leaves are salted opaque commitments with selective disclosure; an `op:erase` destroys the salt so the leaf's meaning is unrecoverable while the Merkle proofs stay valid. Auditable and right-to-erasure — a real answer for a program that has to reconcile an audit trail with a patient's erasure request.
- **The reconnaissance tripwire.** `op:lookups` turns "who is enumerating my fleet?" — or "who's been verifying my endpoints?" — into a query: it returns who resolved or RDAP-queried a device's identity, an early warning that someone is walking your inventory, not a post-mortem after the exfil. The private device registry never gave you that.

## Out-of-band, no inline chokepoint — and it fails open.

In a hospital, an identity layer that can go down and take a monitor or an infusion pump with it is a patient-safety hazard, not a security control. Whisper rides existing DNS and IPv6 and adds no inline chokepoint between a device and the network. And if your backend or endpoint authorizes against the DANE/verify path, that plane is built to fail open: when Whisper is reachable it binds to the device's /128 via DANE and verify and the request proceeds identity-enforced; when Whisper is unreachable the check degrades to your existing anchors (UDAP cert · TLS) and connectivity is preserved. Anycast on AS219419, no single node in the path.

> *"An identity layer that can go down and take a bedside device with it is a non-starter. Is this inline?"*
>
> **No — and it fails open.** The identity and revocation planes ride DNS/IPv6 out-of-band; there is no Whisper box wedged into the clinical path. If we're slow or unreachable, the check degrades to the anchors you already run and the device keeps operating. That's an availability property your assessors can test, not a promise.

## Additive to your stack. Mapped to your standards. Availability-safe by construction.

Three planes — Identity, Attribution graph, Egress governance — rest on one primitive (the address is the identity, AS219419, 2a04:2a01::/32) and exit into the stack you already run: your SIEM (Splunk & Sentinel today), machine-readable formats (STIX 2.1 / TAXII, CEF / ECS — on the roadmap), and your standards (§524B · HIPAA · MDR · IEC 62443). The Splunk connector ships today; the rest of the machine-readable exports are on the roadmap.

- **Turnkey HIPAA & §524B evidence.** A UDI-keyed identity register, a live network map, per-device segmentation and one-call containment — direct-additive evidence for the HIPAA NPRM inventory / map / segmentation asks and §164.312(b)/(d), plus a §524B authentication control and the EU MDR §17.4 access requirement. [See the map →](/for-hdos#map)
- **One identity fabric, every vendor.** Derived from the key already in the device or endpoint — no second PKI, no enrollment portal, no re-flashing the fielded fleet. Whether it's an infusion pump, a PACS node or a FHIR server, it's one verifiable /128 you, your HIE and any relying party can check. Non-repudiable telemetry, instant cross-org offboarding.
- **Additive & availability-safe.** Rides existing DNS/IPv6, adds no inline chokepoint, and fails open — a Whisper outage never bricks a bedside device; checks degrade to your existing anchors. Anycast on AS219419, no single node in the path.
- **Feeds the SIEM you already run.** Depth on top of the stack you own — a machine-readable feed that makes your IoMT sensor and threat-intel sharper. The Splunk, Microsoft Sentinel and OpenCTI connectors ship today; STIX 2.1 over TAXII is on the roadmap. It doesn't replace your Claroty / Armis / Forescout — it plugs into them. [See the comparison →](/compare)
- **Flat, predictable pricing.** Per-device / year and flat — not per-transaction, not usage-metered. Clear ROI: analyst-hours saved on disposable-IP correlation, one `revoke` instead of a re-imaging campaign or a truck-roll, and an OCR / breach exposure avoided is the whole year's budget. [See pricing →](/pricing)
- **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. Registry-anchored, RDAP-resolvable space — operated with the discipline that implies. POC → pilot → enterprise, keyless to start.

## Don't take our word for it — our API isn't in the trust path.

Two tiers, by design. No key: anyone can verify a device or FHIR endpoint's identity, resolve it, and see who's been checking it — trustless, anchored at the IANA root, even outside your trust community. Your key: bind a device to the UDI or Endpoint.identifier it carries, govern its egress, and produce the HIPAA / §524B evidence in two calls.

```
# keyless — re-derive and verify any device or FHIR endpoint identity, trustless
$ whisper verify --trustless 2a04:2a01:d1c::5e
  ✓ DNSSEC chain valid to the IANA root
  ✓ DANE-EE (TLSA) leaf matches the identity's key
  ✓ RDAP: registered under AS219419 · 2a04:2a01::/32
  identity: VERIFIED — and our own API was never trusted

# the address is the device — reverse DNS names it by its UDI
$ dig -x 2a04:2a01:d1c::5e +short
  udi-00860001234567.dev.example-hdo.whisper.online.

# its ordered lifecycle — every mint and revoke, from the public transparency log
$ curl -s https://whisper.online/ip/2a04:2a01:d1c::5e/transparency
```

```
# bind a device to the UDI it carries — or a FHIR endpoint to its Endpoint.identifier
$ export WHISPER_API_KEY=whisper_live_xxx
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" --data-urlencode "q=CALL whisper.agents({op:'connect', args:{tier:'wireguard',
       identity_public_key:'<base64 SPKI of the device key>',
       device_id:'00860001234567'}})"   # device_id = the FDA UDI (DI)
  → identity 2a04:2a01:d1c::5e   DNSSEC + DANE live
$ whisper policy set --default deny --allow ehr.example-hdo.org,vna.example-hdo.org   # micro-segment at the device
$ whisper logs 2a04:2a01:d1c::5e            # per-/128 activity — §164.312(b) audit-control evidence
$ whisper kill --revoke 2a04:2a01:d1c::5e   # contain a compromise — worldwide, at DNS-TTL
```

## Give the device an identity — and the evidence to prove it.

Bind the UDI or FHIR Endpoint.identifier your device already carries to a routable, revocable /128. Direct-additive evidence for the HIPAA Security Rule NPRM asks and a §524B control; a public DNS/DANE anchor for the identity UDAP asserts privately — additive, out-of-band, availability-safe, and honest about where the line is. Keyless to try, one call to provision, one more to revoke.

Or run `whisper verify --trustless` right now.