Wearables & Remote Patient Monitoring cybersecurity.

• Continuous vital-sign patches (ECG, SpO2, temp, respiration)
• Hospital-at-home and post-acute monitoring kits
• Chronic-disease RPM (CHF, COPD, hypertension)
• Maternal and pediatric RPM
• Medication adherence trackers

• Wearable ↔ phone / gateway (BLE, authenticated pairing)
• Gateway ↔ cloud (TLS, mutual auth where possible)
• Cloud ↔ clinician dashboard (SSO, RBAC)
• Cloud ↔ EHR / payer / care-coordination platforms (FHIR)
• Cloud ↔ alarm / escalation pipelines (rate-limited, audited)

Do consumer wearables need an FDA cyber package?

Only when you make a clinical claim and pursue clearance (510(k), De Novo, or PMA). The moment you do, the full premarket cyber package applies - threat model, SBOM, security architecture, authenticated penetration testing, MDS2, labeling, and a postmarket plan under section 524B. Wellness-only positioning avoids the cyber package, but the line is narrower than most consumer-electronics teams expect, so we frequently help scope a Pre-Sub to settle it.

What's the right BLE pairing mode for a clinical wearable?

Authenticated pairing under LE Secure Connections - either numeric comparison or out-of-band - is the expected baseline for any clinical wearable. Just Works pairing is hard to defend in a threat model because it offers no MITM protection, and 'Just Works on first pair, encrypted thereafter' has known downgrade attacks. The threat model documents the chosen pairing mode, the rationale, and the residual risk; the IFU tells the patient what 'good' looks like.

How do you test the OTA firmware update path?

We verify cryptographic signature validation against a hardware-rooted trust anchor where available, anti-rollback enforcement, atomic install with A/B partitioning or equivalent, and recovery behavior under interrupted updates. The cloud delivery path's authentication, integrity, and authorization are pen-tested separately, and we exercise downgrade and substitution scenarios to ensure a hostile peer or compromised cloud cannot push an older or malicious build.

Do you cover the EHR integration in scope?

Yes when the EHR integration is part of the cleared system. Typically the FHIR or HL7 endpoint, its authentication (SMART on FHIR, mTLS, OAuth), its authorization model (scopes, claims, tenancy), and its rate-limiting/abuse-resistance properties are tested as part of the wearable system. Findings here often have outsized impact because a single integration may serve many patients across many provider tenants.

What about battery-drain and DoS attacks against the sensor?

Battery exhaustion and DoS are recognized safety-relevant cyber threats for wearables - a forced-pairing storm, a malicious BLE peer, or a malformed advertisement flood can drain a clinical device and silence its alarms. We model and exercise these scenarios on the device and document the mitigations (rate limiting, peer denylisting, exponential backoff, low-battery alarm integrity) in the SPDF and labeling. The IEC 14971 risk file ties the controls back to specific patient hazards.

How is multi-tenant cloud isolation tested?

We perform cross-tenant authorization testing (BOLA), key-scoping and KMS-policy verification, audit-trail review, and tenant-migration / soft-delete / undelete flow testing. Every cross-tenant access we surface is treated as a critical finding because in this segment a single authorization gap can expose continuous physiologic data for thousands of patients. Findings are tied back to specific code paths so remediation is unambiguous.

What's the playbook for cellular-connected wearables and patches?

Cellular-connected patches and wearables get an additional radio-stack review: APN configuration, certificate pinning on the cellular backhaul, IMEI/IMSI handling, and SIM lifecycle (eSIM provisioning, deactivation, replay). We also pen-test the device-management layer that controls the cellular fleet because compromise there can affect every patient device simultaneously. The threat model includes the carrier as an explicit untrusted-but-contractually-bound party.

How do you handle continuous physiologic data on the cloud (PHI scale)?

Continuous data raises the impact ceiling for any confidentiality finding, so we test encryption at rest and in transit, key custody, region/residency controls, audit logging, and retention with the same rigor as a high-volume health platform. The SPDF documents the data classification, lawful basis, retention windows, and access patterns, and pen testing exercises the highest-volume read paths (clinician dashboards, exports, research APIs) under realistic authorization conditions.

Do you cover companion mobile apps separately?

Companion apps get the standard mobile premarket package: OWASP MASVS L2 baseline with MSTG-driven test cases, secure storage of pairing material, TLS pinning, root/jailbreak detection where clinically justified, and authorization checks against both the device and any cloud APIs. Findings on the app are tied back to the device threat model so the system view stays coherent.

What standards stack applies to RPM and clinical wearables?

Typical baseline: FDA 2026 final premarket cybersecurity guidance, AAMI SW96, AAMI TIR57, IEC 62304 (typically Class B for monitoring-only, Class C when therapy is in the loop), ISO 14971, OWASP MASVS for the app, OWASP ASVS for the cloud, plus Bluetooth SIG profile-specific security requirements and applicable IEC 60601 particulars where the device is electrically connected to the patient. EU manufacturers add MDR Annex I §17.2 and MDCG 2019-16.

How long does an RPM/wearables premarket cyber engagement typically take?

For a connected wearable with mobile app, cloud, and EHR integration, end-to-end premarket cyber work generally runs 6-12 weeks. Threat modeling and SBOM front-load in weeks 1-3, device/app/cloud/EHR pen testing runs in weeks 3-9, and the consolidated submission package and postmarket plan close in the final weeks - all under a written clearance guarantee.