arXiv:2607.13122v1 [cs.CR] 14 Jul 2026
Designing a GDPR-Compliant Security Architecture for Remote Elderly Care Systems: A Privacy-by-Design Approach Md. Rahid Parvez
Mikael Soini
School of ICT and Industrial Management Metropolia University of Applied Sciences Helsinki, Finland [email protected]
School of ICT and Industrial Management Metropolia University of Applied Sciences Helsinki, Finland [email protected]
Abstract—IoMT-based remote elderly care systems generate continuous streams of sensitive health data, yet existing security architectures have not simultaneously addressed three interdependent challenges: GDPR-compliant edge-layer pseudonymisation, elderly-specific zero-interaction usability as a binding architectural constraint, and integrated STRIDE-based threat validation within a single unified design. This paper presents the Secure Edge Gateway (SEG) framework - a software-simulationvalidated integrated IoMT security architecture for elderly care designed to resolve all three dimensions of this tripartite gap simultaneously. An ESP32-WROOM-32 residential gateway enforces MAC address whitelisting, HMAC-SHA256 cryptographic pseudonymisation before any network transmission, AES-128CBC payload encryption, and TLS 1.3 transport security, in compliance with GDPR Articles 25 and 32. The framework is validated through software-based simulation, full STRIDE threat modelling across all six categories, attack tree analysis, GDPR compliance mapping across nine regulatory obligations, and a Data Protection Impact Assessment (DPIA) under Article 35. Published benchmarks confirm MQTT consumes 6–8% less energy than HTTP in comparable IoT deployments, and edge processing achieves sub-50 ms response latency versus 200– 700 ms for cloud-only systems. The results demonstrate that GDPR compliance and operational efficiency are complementary – not competing – objectives in resource-constrained IoMT deployments for elderly care. Index Terms—Internet of Medical Things, GDPR, Privacy-byDesign, STRIDE, Edge Computing, AES-128, MQTT, TLS 1.3, Pseudonymisation, Elderly Care, Cybersecurity, Remote Patient Monitoring
I. I NTRODUCTION Contemporary healthcare systems face an unprecedented demographic challenge: Eurostat projects that individuals aged 65 and above will comprise approximately 29% of the EU population by 2050, exerting substantial pressure on institutional healthcare infrastructure [1]. The Internet of Medical 0 Md. Rahid Parvez is with the School of ICT and Industrial Management at Metropolia University of Applied Sciences, Helsinki, Finland (e-mail: [email protected]). This work was completed as part of a Master’s thesis at Metropolia University of Applied Sciences, April 2026. 0 A prior version of this work was published as a Master’s thesis in the Theseus Open Repository of Metropolia University of Applied Sciences (URN:NBN:fi:amk-202604186859), April 2026.
Things (IoMT) – interconnected wearable sensors, residential gateways, and cloud-hosted analytical platforms – has emerged as the principal technological enabler of home-based elderly monitoring [2]. The data processed by IoMT systems constitutes a ‘special category’ under GDPR Article 9 [3], warranting heightened protection. Compromised IoMT systems pose direct patient safety risks – falsified vital sign readings, suppressed emergency alerts, or manipulated device actuation – extending beyond privacy harms to physical injury [4], [5]. Despite well-established cryptographic protocols, their application to resource-constrained IoMT for elderly care remains insufficiently addressed in existing literature [6]. Three principal impediments persist: (1) computational and energy constraints precluding heavyweight cryptography on sensor nodes; (2) architectural fragmentation where security controls are implemented piecemeal; and (3) regulatory-technical discontinuity between GDPR compliance requirements and engineering feasibility. These impediments manifest as a tripartite research gap [6]: no prior validated work has simultaneously resolved edgelayer GDPR-compliant pseudonymisation, elderly-specific zero-interaction usability as a first-class architectural constraint, and systematic STRIDE-based validation of a complete unified architecture. This paper addresses all three through the SEG framework. A. Research Question How can a GDPR-compliant, edge-layer security architecture be designed and validated to simultaneously address the tripartite gap of cryptographic pseudonymisation, elderlyspecific zero-interaction usability, and integrated STRIDEbased threat validation in resource-constrained IoMT deployments for remote elderly care? II. BACKGROUND AND R ELATED W ORK A. IoMT Architecture IoMT systems for elderly care are organised into three functional layers [7], [8]. The Perception Layer comprises
resource-constrained wearable sensors – pulse oximeters, thermometers, accelerometers – characterised by limited processing capacity and small battery power supplies, which fundamentally constrain the range of deployable security mechanisms [9]. The Network Layer performs mediation via a residential gateway, aggregating sensor data and managing secure upstream transmission; this layer is the primary focus of this work. The Application Layer encompasses cloud infrastructure and clinical interfaces. B. GDPR Requirements GDPR Article 25 mandates Privacy-by-Design [10]: data protection must be integrated from inception, not retrofitted post-deployment. Cavoukian’s seven foundational principles [11] – proactive protection, privacy as default, embedded design, full functionality, end-to-end security, visibility, and user respect – underpin this mandate and are directly operationalised in the SEG framework. Article 32 explicitly requires pseudonymisation and encryption as appropriate technical measures. Article 35 mandates a Data Protection Impact Assessment (DPIA) for high-risk processing, which health data monitoring constitutes. C. STRIDE Threat Model OWASP IoT security guidelines [12] identify authentication, access control, and encrypted communication as primary requirements for medical IoT deployments. STRIDE provides a systematic threat taxonomy across six categories – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege – as formalised by Shostack [13]. Each STRIDE category maps directly to specific architectural controls in the SEG framework. D. Related Work and Research Gap Table I presents a structured comparison of the most closely related prior works. Rahmani et al. [14] correctly identified the edge gateway as the appropriate security enforcement locus but did not address GDPR compliance or elderly usability. Koutli et al. [15] addressed GDPR partially but performed pseudonymisation at the cloud layer, leaving patient-identifiable data unprotected in transit. Rahman et al. [16] proposed a blockchain approach that provides audit immutability but imposes consensus latency incompatible with real-time emergency monitoring. Sun et al. [17] provide a comprehensive IoMT security survey but do not propose a validated architecture. Islam et al. [18] propose a hybrid fogedge architecture with health monitoring capability but without GDPR compliance mapping or elderly-specific design. Li et al. [19] identify key security issues for precision health IoMT but stop short of an architectural solution addressing all three gap dimensions. Recent work has reinforced the significance of the identified gaps. Dutta and Puthal [20] proposed a fuzzy logic and blockchain-enhanced IoMT-edge-cloud framework for eHealth in Society 5.0 (IEEE Access, 2024), demonstrating that elderly-specific IoMT architectures are an active research
priority – yet their framework does not address GDPR Art. 25 edge-layer pseudonymisation or zero-interaction usability. A CHI 2025 empirical study by Saka and Das [21] found that only 13.64% of elderly IoT users feel confident in existing privacy protections, with “complex security settings” generating distrust and anxiety – directly corroborating the clinical necessity of the zero-interaction constraint adopted in the SEG. A systematic review by the same authors [22], accepted at ASIA CCS 2026, confirms that while more than 70% of IoT studies implement encryption, fewer than 50% address usability. No prior work addresses all three tripartite dimensions simultaneously. III. M ETHODOLOGY This research adopted Design Science Research Methodology (DSRM) [23], appropriate for research whose primary scientific contribution is a novel artefact – the SEG framework. DSRM accommodates rigorous artefact design and validation without requiring a live clinical deployment context. Three sequential phases structured the research. Phase 1 (Problem Analysis) conducted a structured literature search across IEEE Xplore, ACM Digital Library, Scopus, and Google Scholar (2015–2025), identifying the tripartite gap and establishing clinical constraints for elderly care. Phase 2 (Design and Development) specified the SEG architecture, applied STRIDE threat modelling, and conducted an analytical DPIA structured in accordance with GDPR Article 35 and EDPB notification guidelines [24]. Phase 3 (Validation and Evaluation) validated the architecture through softwarebased PoC simulation, attack tree analysis, GDPR compliance mapping, and performance benchmarking against published literature. A feedback loop between Phases 2 and 3 ensured residual risk assessment before validation proceeded [23]. IV. SEG F RAMEWORK A RCHITECTURE The SEG framework is formally defined as: a threetiered, edge-computing IoMT security architecture that enforces GDPR Article 25-compliant cryptographic pseudonymisation at the residential network boundary, implements elderlyspecific zero-interaction usability constraints as binding architectural requirements, and has been validated against the complete STRIDE threat taxonomy within a unified design. A. System Architecture The architecture comprises three security zones. Zone 1 (Patient Zone) contains wearable sensors with no direct internet connectivity, connected to the gateway via wired protocols – I2C for the MAX30100 pulse oximeter (address 0x57) and 1Wire for the DS18B20 temperature sensor. Zone 2 (Residential Security Perimeter) houses the ESP32-WROOM-32 gateway, which enforces all security operations before data leaves the residential environment. Zone 3 (Cloud Zone) provides clinical access via RBAC and two-factor authentication.
TABLE I C OMPARISON OF PRIOR WORKS AGAINST THE TRIPARTITE RESEARCH GAP. Prior Work
Gap 1: Edge Pseudo.
Gap 2: Elderly UX
Gap 3: STRIDE
GDPR Art.25&32
Rahmani et al. [14] Koutli et al. [15] Rahman et al. [16] Sun et al. [17] Islam et al. [18] Dutta & Puthal [20] SEG (This Work)
Not implemented Cloud-layer only Not implemented Survey only Not implemented Not implemented Edge-layer
Not addressed Not addressed Not addressed Not addressed Not addressed Not addressed Zero-interaction
Not conducted Not conducted Not conducted Not conducted Not conducted Not conducted Full 6-category
Not addressed Partial Not addressed Survey only Not addressed Not addressed Art.25 & 32
This platform was selected for its hardware AES acceleration – critical for energy-efficient encryption on a battery-adjacent device – and native TLS 1.3 support via the ESP-TLS library. C. Data Processing Pipeline The pseudonymisation stage warrants particular attention as the primary privacy-enforcement step. Upon receipt of a validated sensor reading, the gateway retrieves the patient’s registered identity and applies HMAC-SHA256 to derive a deterministic HashID – for example, ‘a3f9c2b17e4d8f01’ – which replaces the patient identity field in the JSON payload before any further processing or transmission. Health data and patient identity are thereby separated at the earliest feasible point in the pipeline, consistent with GDPR Article 4(5) and ENISA pseudonymisation best practices [26]. D. Security Enforcement Mechanisms
Fig. 1. High-level SEG security architecture across three zones.
B. Hardware Specification The SEG gateway is specified on the ESP32-WROOM-32D platform [25]: dual-core Xtensa LX6 at 240 MHz, 520 KB SRAM, hardware-accelerated AES cryptographic engine, and integrated dual-mode 802.11 b/g/n Wi-Fi + BLE 4.2 radio.
ENISA-Compliant Pseudonymisation: In compliance with GDPR Article 32(1)(a) and ENISA pseudonymisation best practices [26], the gateway derives a pseudonymous HashID from the patient MAC address using HMAC-SHA256 with a gateway-resident secret key. The resulting 16-character hexadecimal digest (64-bit entropy) replaces the patient identity field before any network transmission. The gateway-side HMAC key is stored in persistent flash storage and updated only through a secured initial installation procedure conducted by a trained technician. This edge-layer pseudonymisation – rather than cloud-layer – is the primary architectural innovation: patient-identifiable data never traverses the public internet. AES-128-CBC Payload Encryption: The pseudonymised JSON payload is encrypted using AES-128-CBC with a cryptographically random initialisation vector per transmission. AES-128 was selected over AES-256 based on empirical evidence that both provide equivalent security against all computationally feasible attacks, while AES-128 consumes measurably less energy per operation on resource-constrained hardware [27]. TLS 1.3 + MAC Whitelisting: All MQTT communication is encapsulated within a TLS 1.3 cryptographic tunnel [28], [29], providing transport-layer confidentiality and mutual authentication. The gateway cross-references the source device MAC address against a flash-stored whitelist prior to process-
ing any packet; unregistered addresses are silently discarded, mitigating the STRIDE Spoofing threat. Elderly Zero-Interaction Constraint: Consistent with empirical evidence that elderly users exhibit lower tolerance for complex technological interaction and heightened technologyinduced anxiety [30], the SEG is designed so that patients need perform no action beyond wearing the sensor devices. All authentication, pairing, encryption, and transmission occur automatically. This architectural choice simultaneously eliminates social engineering attack vectors including phishing, credential theft, and inadvertent misconfiguration.
Software-based PoC validation: A Python-based simulation of the complete SEG processing pipeline – MAC whitelisting → HMAC-SHA256 pseudonymisation → AES128-CBC encryption → JSON serialisation → MQTT formatting – confirmed the operational feasibility of the SEG pipeline, with each processing stage executing correctly in sequence, as shown in the simulation output log.
V. VALIDATION AND R ESULTS
Implementing GDPR Article 25 on resource-constrained microcontroller hardware reveals fundamental tensions between regulatory ideality and engineering reality. The data minimisation principle requires upfront clinical judgements about which health parameters are ‘strictly necessary’. The SEG resolves this by restricting collection to three clinically universal elderly monitoring parameters: heart rate, peripheral oxygen saturation, and body temperature. Pseudonymisation at the gateway layer – rather than a cloud service – ensures the Article 4(5) identity-data separation is enforced at the earliest feasible point in the data pipeline, providing stronger privacy guarantees than any cloud-layer pseudonymisation approach.
A. STRIDE Threat Analysis Table II presents the detailed technical security risk assessment of the SEG architecture, mapping each STRIDE threat category to a specific attack scenario, the target component, the qualitative risk severity rating assessed using CVSS v3.1 categories, and the architectural countermeasure implemented to mitigate each identified threat [13]. The attack tree analysis demonstrates that successful compromise of the Edge Gateway requires an attacker to overcome multiple independent defensive layers, consistent with the Defence-in-Depth security principle [28], [29]. No single point of failure was identified across all six STRIDE categories within the scope of this simulation-based analysis. B. GDPR Compliance Mapping Table III presents the compliance mapping of SEG architectural features against GDPR Articles 25 and 32 obligations. All nine identified regulatory obligations are satisfied. C. Performance Analysis Note on evaluation methodology: All performance figures cited in this section are derived exclusively from published peer-reviewed empirical benchmarks, as noted per citation. Physical hardware measurement falls outside the scope of this simulation-based study and is identified as Priority 1 in the future work roadmap. Protocol energy: MQTT’s persistent TCP connection eliminates per-request handshake overhead. Yassein et al. [31] document MQTT’s 2-byte binary fixed header versus HTTP’s 200– 800-byte text header per transaction. Empirical measurement by Jara Ochoa et al. [32] demonstrates MQTT consumes 6– 8% less energy than HTTP under comparable IoT deployment conditions – a meaningful difference for continuous, batteryadjacent health monitoring. Latency: Edge computing consistently achieves sub-50 ms response latencies for local gateway processing – reported as low as 11.5 ms in comparable edge gateway deployments [33] and confirmed across IoMT-specific deployments [34], [35] – compared to 200–700 ms for cloud-only processing under normal conditions. The SEG’s edge-local emergency alerting provides sub-50 ms propagation independent of cloud connectivity – a clinically critical property for acute cardiac or respiratory event detection.
VI. D ISCUSSION A. Privacy-by-Design Implementation Challenges
B. Zero-Interaction Usability as Clinical Necessity A security architecture that imposes cognitive or interaction burden on elderly users ultimately fails its clinical purpose. Saka and Das [21] found empirically that only 13.64% of elderly IoT users feel confident in existing protections, with complex security settings generating distrust and anxiety – recommending ‘privacy and security by design’ with simplified interfaces. A systematic review by the same authors [22] confirms this gap persists across the most recent literature: fewer than 50% of IoT studies address usability. By eliminating all patient-facing authentication – no passwords, no manual pairing, no active inputs – the SEG simultaneously removes the entire class of social engineering attack vectors. This operationalises the zero-interaction constraint recommended by [21] as a binding architectural requirement rather than a post-hoc usability concern, consistent with Steele et al.’s [30] earlier findings on elderly wireless sensor acceptance. C. Comparison with Existing Systems The SEG framework demonstrates improvements across all evaluated dimensions relative to conventional cloud-based IoMT deployments: edge processing achieves sub-50 ms latency (as low as 11.5 ms in comparable deployments [33]) versus 200–700 ms cloud-only [34], [35]; MQTT reduces energy consumption by 6–8% versus HTTP [31], [32]; and pseudonymisation is applied before transmission. The central finding challenges the common assumption of an inherent trade-off between security and operational efficiency: in the SEG architecture, security controls and performance are mutually reinforcing objectives.
TABLE II T ECHNICAL SECURITY RISK ASSESSMENT AND COUNTERMEASURES . R ISK LEVELS ASSESSED USING CVSS V 3.1 QUALITATIVE CATEGORIES . STRIDE Threat
Attack Scenario
Target Component
Risk Level
Architectural Countermeasure
Spoofing
Attacker deploys rogue sensor with fabricated health data to inject falsified readings
BLE / Gateway Interface
High
MAC address whitelisting: unregistered devices silently discarded prior to data processing
Tampering
Man-in-the-middle interception and modification of health data values in transit
Network Stream
Data
Critical
HMAC integrity verification: modified payloads detected and rejected; AES-128 encryption prevents plaintext manipulation
Repudiation
Authorised user performs administrative actions and subsequently denies them, exploiting absence of audit trail
Cloud Database / Gateway
Medium
Comprehensive timestamped audit logging at both gateway and cloud layers; log integrity protected via append-only storage
Information Disclosure
Attacker captures transmitted MQTT packets or accesses cloud storage to read patient identity and health records
Storage / Network
Critical
Cryptographic pseudonymisation segregates identity from health data; AES-128 renders captured payloads computationally undecipherable
Denial Service†
of
Attacker floods gateway with malformed MQTT connection requests to exhaust processing capacity and suppress alerts
Gateway
High
Connection rate limiting: threshold-exceeded connections rejected; edge processing maintains alert functionality independently of internet availability
Elevation of Privilege
Attacker exploits firmware vulnerability to acquire administrative gateway control, enabling full system compromise
Gateway Firmware
High
Principle of least privilege enforced; administrative interface restricted to local physical access; regular firmware integrity verification
OS
/
† Large-scale volumetric DDoS attacks must be mitigated at the upstream ISP network level; the edge-based rate limiting implemented here is designed
specifically to address local DoS attempts [28], [29]. TABLE III GDPR COMPLIANCE MAPPING – ALL NINE OBLIGATIONS ARCHITECTURALLY ADDRESSED . GDPR Obligation
Article
SEG Implementation
Status
Data Protection by Design
Art. 25(1)
Security integrated from initial design phase
Architecturally addressed
Data Minimisation
Art. 25(1)
Three parameters only: HR, SpO2 , Temperature
Architecturally addressed
Privacy by Default
Art. 25(2)
Maximum protection without user configuration
Architecturally addressed
Pseudonymisation
Art. 32(1)(a)
HMAC-SHA256 HashID at residential edge boundary
Architecturally addressed
Encryption
Art. 32(1)(a)
AES-128-CBC application + TLS 1.3 transport
Architecturally addressed
Ongoing Confidentiality
Art. 32(1)(b)
MAC whitelist + dual-layer encryption
Architecturally addressed
Ongoing Integrity
Art. 32(1)(b)
HMAC-SHA256 per-packet integrity verification
Architecturally addressed
Ongoing Availability
Art. 32(1)(b)
Rate limiting; edge-local alerting
Architecturally addressed
Audit Logging
Art. 32(1)(c)
Timestamped tamper-evident event logs
Architecturally addressed
D. Limitations This study acknowledges the following limitations, each defining a future work priority. The evaluation methodology
is simulation-based rather than empirical – physical hardware energy consumption and latency were not directly measured. Synthetic rather than genuine patient data was employed. The regulatory analysis is confined to the GDPR framework
applicable within the EEA. Physical hardware deployment and empirical HCI testing with real elderly patients fall outside the current study scope. MAC whitelisting does not address physical sensor theft scenarios. VII. C ONCLUSIONS This paper presented the Secure Edge Gateway (SEG) framework, addressing the tripartite research gap in IoMT security for elderly care through three original contributions. Contribution 1: A software-simulation-validated IoMT architecture implementing GDPR Article 25-compliant HMACSHA256 cryptographic pseudonymisation at the residential edge boundary before any network transmission, ensuring patient-identifiable data never traverses the public internet. Contribution 2: A zero-interaction security model implementing elderly-specific usability constraints as first-class architectural requirements, eliminating all patient-facing authentication and simultaneously removing social engineering attack surfaces. Contribution 3: A systematic STRIDE-based threat validation – across all six categories – of a complete, unified IoMT architecture incorporating both edge pseudonymisation and zero-interaction usability constraints. The central finding – that GDPR compliance and operational efficiency are complementary rather than competing objectives in resource-constrained IoMT elderly care – has significant implications for practitioners designing European market healthcare monitoring systems. Future work will pursue five phases: physical ESP32WROOM-32D hardware deployment with empirical energy and latency measurement; TinyML-based personalised anomaly detection on the edge device [36]; lightweight blockchain audit integrity; IPv6 and 5G scalability; and X.509 cryptographic device attestation to address the physical theft limitation. ACKNOWLEDGMENT The authors would like to thank Principal Lecturer Päivi Haho and Senior Lecturer Sakari Lukkarinen of Metropolia University of Applied Sciences for their valuable guidance and feedback during the preparation of this work. R EFERENCES [1] European Commission, “The 2021 Ageing Report,” Publications Office of the European Union, Luxembourg, 2021. [2] S. Razdan and S. Sharma, “Internet of Medical Things (IoMT): Overview, Emerging Technologies, and Case Studies,” IETE Tech. Rev., vol. 39, no. 4, pp. 775–788, 2022. [3] European Parliament and Council of the European Union, “Regulation (EU) 2016/679 (GDPR),” Official Journal of the European Union, Apr. 2016. [4] F. Kamalov et al., “Internet of Medical Things Privacy and Security,” Sustainability, vol. 15, no. 4, p. 3317, 2023. [5] ENISA, “ENISA Threat Landscape 2025,” European Union Agency for Cybersecurity, Oct. 2025. [6] R. U. Z. Wani, F. Thabit, and O. Can, “Security and privacy challenges for IoMT: A systematic review,” Secur. Priv., vol. 7, no. 5, p. e409, 2024. [7] A. Gatouillat et al., “Internet of Medical Things: A Review of Recent Contributions Dealing With Cyber-Physical Systems in Medicine,” IEEE Internet Things J., vol. 5, no. 5, pp. 3810–3822, 2018.
[8] I. Lee and K. Lee, “The Internet of Things (IoT): Applications, investments, and challenges for enterprises,” Bus. Horiz., vol. 58, no. 4, pp. 431–440, 2015. [9] M. A. Al-Garadi et al., “A Survey of Machine and Deep Learning Methods for Internet of Things (IoT) Security,” IEEE Commun. Surv. Tutor., vol. 22, no. 3, pp. 1646–1685, 2020. [10] European Parliament and Council, “Art. 25 GDPR, Data protection by design and by default,” Official Journal of the European Union, 2016. [11] A. Cavoukian, “Privacy by Design: The 7 Foundational Principles,” Information and Privacy Commissioner of Ontario, 2009. [12] The OWASP Foundation, “OWASP Internet of Things Project,” 2024. [13] A. Shostack, Threat Modeling: Designing for Security. Indianapolis, IN: Wiley, 2014. [14] A. M. Rahmani et al., “Smart e-Health gateways at the edge of healthcare internet-of-things: A fog computing approach,” Future Gener. Comput. Syst., vol. 78, pp. 641–658, 2018. [15] M. Koutli et al., “Secure IoT e-Health Applications using VICINITY Framework and GDPR,” in Proc. IEEE DCOSS, 2019, pp. 263–270. [16] Md. A. Rahman et al., “Blockchain-Based Mobile Edge Computing Framework for Secure Therapy Applications,” IEEE Access, vol. 6, pp. 72469–72478, 2018. [17] Y. Sun, F. P.-W. Lo, and B. Lo, “Security and Privacy for the Internet of Medical Things Enabled Healthcare Systems,” IEEE Access, vol. 7, pp. 183339–183355, 2019. [18] U. Islam et al., “A hybrid fog-edge computing architecture for real-time health monitoring in the Internet of Medical Things,” Sci. Rep., vol. 15, no. 1, p. 25655, 2025. [19] N. Li et al., “A review of security issues for precision health in the era of IoMT,” Secur. Saf., vol. 2, p. 2022010, 2023. [20] J. Dutta and D. Puthal, “Advancing eHealth in Society 5.0: A Fuzzy Logic and Blockchain-Enhanced Framework for Integrating IoMT, Edge, and Cloud With AI,” IEEE Access, vol. 12, pp. 192405–192423, 2024, doi: 10.1109/ACCESS.2024.3520799. [21] S. Saka and S. Das, “‘Watch My Health, Not My Data’: Understanding Perceptions, Barriers, Emotional Impact, & Coping Strategies Pertaining to IoT Privacy and Security in Health Monitoring for Older Adults,” in Proc. ACM CHI, Yokohama, Japan, Apr. 2025, doi: 10.1145/3706598.3714019. [22] S. Saka and S. Das, “SoK: Reviewing Two Decades of Security, Privacy, Accessibility, and Usability Studies on Internet of Things for Older Adults,” in Proc. ACM ASIA CCS, Bangalore, India, Jun. 2026, doi: 10.1145/3779208.3785270. [23] K. Peffers et al., “A Design Science Research Methodology for Information Systems Research,” J. Manag. Inf. Syst., vol. 24, no. 3, pp. 45–77, 2007. [24] European Data Protection Board, “Guidelines 01/2021 on Examples Regarding Personal Data Breach Notification,” Jan. 2022. [25] Espressif Systems, “ESP32-WROOM-32 Datasheet v3.4,” 2023. [26] ENISA, “Pseudonymisation Techniques and Best Practices,” European Union Agency for Cybersecurity, Nov. 2019. [27] C.-W. Hung and W.-T. Hsu, “Power Consumption and Calculation Requirement Analysis of AES for WSN IoT,” Sensors, vol. 18, no. 6, p. 1675, 2018. [28] NIST, “Special Publication 800-207: Zero Trust Architecture,” National Institute of Standards and Technology, Aug. 2020. [29] NIST, “Special Publication 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations,” 2023. [30] R. Steele et al., “Elderly persons’ perception and acceptance of using wireless sensor networks to assist healthcare,” Int. J. Med. Inf., vol. 78, no. 12, pp. 788–801, 2009. [31] M. B. Yassein, M. Q. Shatnawi, S. Aljwarneh, and R. Al-Hatmi, “Internet of Things: Survey and open issues of MQTT protocol,” in Proc. Int. Conf. Engineering & MIS (ICEMIS), Monastir, Tunisia, May 2017, pp. 1–6, doi: 10.1109/ICEMIS.2017.8273112. [32] H. J. Jara Ochoa, R. Peña, Y. Ledo Mezquita, E. Gonzalez, and S. Camacho-Leon, “Comparative Analysis of Power Consumption between MQTT and HTTP Protocols in an IoT Platform Designed and Implemented for Remote Real-Time Monitoring of Long-Term Cold Chain Transport Operations,” Sensors, vol. 23, no. 10, p. 4896, 2023, doi: 10.3390/s23104896. [33] P. Pace, G. Aloi, R. Gravina, G. Caliciuri, G. Fortino, and A. Liotta, “An Edge-Based Architecture to Support Efficient Applications for Healthcare Industry 4.0,” IEEE Trans. Ind. Informat., vol. 15, no. 1, pp. 481–489, 2018, doi: 10.1109/TII.2018.2843169.
[34] P. Verma and S. K. Sood, “Fog Assisted-IoT Enabled Patient Health Monitoring in Smart Homes,” IEEE Internet Things J., vol. 5, no. 3, pp. 1789–1796, 2018, doi: 10.1109/JIOT.2018.2803201. [35] P. Dong et al., “Edge Computing Based Healthcare Systems: Enabling Decentralized Health Monitoring in Internet of Medical Things,” IEEE Netw., vol. 34, no. 5, pp. 254–261, 2020. [36] R. Sanchez-Iborra and A. F. Skarmeta, “TinyML-Enabled Frugal Smart Objects: Challenges and Opportunities,” IEEE Circuits Syst. Mag., vol. 20, no. 3, pp. 4–18, 2020.