## 2 Related Work and Security Landscape in mHealth
### Security Challenges Across Wearables, Mobile, and Backend Layers  
MHealth applications function as complex ecosystems involving multiple components, including wearable devices, Android based smartphones, and containerized backends. The capability to deliver continuous, personalized care through real-time diagnostics introduces distinct security challenges, largely due to the multi-index architecture of mHealth systems. Each component operates under a unique threat model, making it both difficult and impractical to implement comprehensive \"belt and suspenders' protection across all layers and devices\". Wearable devices, in particular smart or \"internet of things\" watches are tied more closely to users' physiological data and must operate autonomously (low power state). Many commercial wearables send biometric information (heart rate, sleep, etc.) wirelessly and, in many cases, do so without encryption, posing a significant security risk. This is often the case with BLE-based applications, where the communication setup between sender and receiver allows a malicious actor to passively sniff data, infer sensitive metadata about the user, and potentially perform injection attacks. An equally concerning aspect of many BLE implementations is the exposure of GATT services. Often, there is minimal or no protection in place for secure pairing or session integrity, which can allow unauthorized access to sensitive health metrics, whether the patient is physically present at the clinic or not [12; 13; 16]. Mobile devices add another attack surface. The permissive, open-source nature of the Android operating systems allows both pre-installed and third-party applications to interact with system components at significant depth. A growing body of evidence confirms that permission abuse, persistent background services and overreaching firmware permissions represent tangible security threats, often enabled by lax permission models under loosely enforced security scenarios such as flowable security. The prior example illustrated a common pattern among health-related applications, which frequently request access to sensitive permissions such as phone number (SMS), device state, microphone, or camera, without providing any clear justification or functional value. Pre-installed may run in the background and share some of this invasive/malicious data externally [17; 18; 19; 20]. Adding more concern to the fragmented threat landscape, fragmentation adds inconsistent security patching on Android devices so known exploits on countless endpoints remain vulnerable. An equally challenging scenario arises in low-resource settings, where mobile phones often serve as the primary computing device and the devices in use are frequently outdated. At the backend, the same applies when healthcare organizations contemplate their development in Docker and Kubernetes architecture. This is to say, although container development is perhaps more modular and scalable, many reasons appeal to insecure defaults, outdated libraries, or poorly designed misconfigured access control models, presuming secure containers. Exposed admin interfaces, connected containers that poorly isolate services, and weak access control allow for lateral movement of unauthorized users in the care network, doubled with potentially privilege escalation and/or payload deployment by poorly secured containers. There have been recent pushes recommending phased migrations to zero-trust orchestration and cloud-edge deployment [15; 21]. The unique and overlapping issues exposed here present the fragmented mHealth security landscape, where vulnerabilities across the misunderstood layers may transfer and interact causing unexpected results. Although previous studies have reviewed security assessments at the level of individual system layers or devices, they do not represent prospective efforts aimed at evaluating systemic risk within interdependent contexts.