## 5 Ethical Considerations and Experimental Environment  
All testing procedures conducted under the PHGL-COVID security assessment occurred in a controlled testing environment, with clear emphasis on ethical obligations and compliance with data protection requirements. There were no real patients, clinical staff, or live healthcare systems included in testing, and this study solely used synthetic biometric data created by computational emulators or physiologically simulated through manual input. This study assured that no personal identification information (PII) or PHRs were ever collected, disclosed, or transferred in the experimentation.  
The wearable device being tested, Samsung Galaxy Watch 7, was in a factory reset state with no earlier pairing history maintained, running Wear OS 4, which was provisioned synthetic health data through utilizing bundled features or testing applications developed for testing only that generated fake sensor streams (i.e., randomized heart rate, step count, SpO2). The related smartphone testing device was a Samsung Galaxy A55 that was configured on Android 14 without rooting it, but with permissions obtained by ADB from developer mode to simulate an adversarial configuration related to a BYOD scenario. Furthermore, the firmware that devices were using was in a widely distributed CSC variant (INS) to realistically replicate plausible inconsistencies of distribution and deployment in markets outside of Europe.  
Backend tests were configured in a virtualized environment hosted on a Linux server (Ubuntu 22.04 LTS) using Docker Engine v24.0.5. No connections were made to production healthcare systems, nor external APIs. All communication endpoints we used were loopback or internal network addresses defined within a private, isolated VLAN. Network configuration prevented accidental data leaks, logging was limited to only update mirrors, and all scanning (Nmap, Nikto, OpenVAS, etc.) was performed against all internal IPs only. The network topology configuration was similar to the real deployment topologies used in the low- to mid-resource clinics, except we were not visible to any external user data, nor any identifiers related to cloud-based providers.  
All data generated from the test including logs, PCAP files, Frida traces, and vulnerability reports were preserved in an encrypted local drive with access restricted to authorized research team members. No telemetry or telemetry-like reporting mechanisms were enabled on any test device or container. Any BLE sniffing experiments we attempted were limited to known UUIDs in test mode, without attempting pairing or injection against any unauthorized paired or unpaired devices.  
This study was conducted in concert with institutional best practices for responsible research, even if formal review board (IRB) approval was not required for our purposes as we had no human subjects. Along those lines, the entire study was designed to follow the European General Data Protection Regulation (GDPR). The use of all components in this study was tested without ever storing or processing any biometric identifiers and we were always aware we must comply with Article 9 related to special category data.  
We chose to use Samsung and Docker based components in our test due to their high market penetration rate, availability within healthcare applications as well as the fact that they aligned with common mHealth use cases. Implementing and using common mHealth components in real-world practice constitutes meaningful and reproducible threat surfaces. The reproducibility of our study was ensured using open source tools to the extent allowable, and the open publication (in an open-access repository) of the associated configurations of our study. Together they maintained the integrity, safety, and replicability of the auditing exercise without erroring on ethical practices, or patient confidentiality.