Key points
- The review by Shahrour, Junejo, and Al Said Ahmad, published in Computer Science Review, screened 3463 records down to 72 studies covering healthcare IoT security across cloud, edge, and fog computing from 2015 through October 2025.
- Six method categories emerged. Architecture design appeared in the most studies at 39, followed by cryptography at 33, authentication and security analysis each at 21, AI and data analytics at 19, and privacy preservation as the least represented at 13.
- Architecture design and cryptography are tightly coupled, appearing together in two thirds of architecture studies, while privacy preservation shows the highest overall tendency to combine with other techniques.
- Nine recurring limitation categories were mapped against the six method categories, and scalability plus deployment and maintenance issues came out as the two weakest points across nearly every technique family.
- The paper’s own numbers shift slightly between the abstract and the body text, a small but telling reminder that even a careful systematic review is not immune to the messiness it is trying to organize.
Why healthcare IoT security is not one problem
Start with the basic shape of the system. A healthcare IoT device, whether it is a glucose monitor, a smart inhaler, or an implanted cardiac sensor, collects data and has to get that data somewhere useful. The obvious answer is the cloud, which offers plenty of storage and computing power for analytics. But routing everything through a distant data center adds latency that matters when the data in question is a cardiac event or a fall. Edge computing processes data closer to the device to cut that latency. Fog computing sits as an intermediate layer, coordinating between edge nodes and the cloud. Each of these three layers, cloud, fog, and edge, solves a different problem and introduces a different set of vulnerabilities.
The review frames this plainly. Centralizing data in the cloud increases the appeal of a single target for attackers. Pushing processing to the edge multiplies the number of access points a network has to defend, since every sensor becomes a potential entry point. Fog computing requires coordination across distributed nodes that adds its own complexity to security. None of these three computing models is inherently safer than the others, they just trade one kind of risk for another, and a healthcare system that uses all three at once, which most do, inherits every one of those tradeoffs simultaneously.
What makes this particularly unforgiving in a hospital or home care setting is that the usual security playbook runs into hard physical limits. A wearable sensor cannot carry a full encryption suite the way a server can, because it has to run for months on a coin cell battery. A pacemaker cannot pause to complete a multi round authentication handshake while a patient’s heart rhythm is doing something dangerous. Security research elsewhere in computing gets to assume more computational headroom than healthcare IoT devices actually have, and that mismatch runs through almost every section of this review.
How the search was actually done
Rather than simply asserting that 72 studies were the right ones, the authors document a search process that is worth walking through, because it explains why this review’s numbers deserve some trust and where they should be read with caution. Following Kitchenham’s guidelines for software engineering systematic reviews, the team built a search string combining cloud, IoT, edge, and fog terms with health app, healthcare, artificial intelligence, and security or privacy, then ran it across nine digital libraries. ScienceDirect returned the most records at 921, Wiley returned 764, SpringerLink returned 586, Google Scholar returned 363, Sage returned 261, PubMed returned 246, ACM returned 231, IEEE Xplore returned 60, and Web of Science returned 31, for a combined 3463 records.
From there the funnel narrows fast. Removing 600 duplicates left 2863 unique articles. Excluding 438 secondary studies such as other reviews and editorials left 686. A title and abstract screening against the research questions cut that to 86. A quality assessment checklist, adapted from prior SLR methodology work by Liao and colleagues, scored each paper across five criteria and identified the final set of 72 relevant publications, labeled Paper ID P01 through P72 in the paper’s supplementary tracking.
What earlier reviews missed
This is not the first systematic review of healthcare IoT security, and the authors are upfront about where it sits relative to prior work. Jayaraj and colleagues focused specifically on radio frequency threats such as jamming, replay, spoofing, and sniffing attacks, covering 2003 through mid 2022, but did not extend into cloud or edge integration. Hemmati and Rahmani reviewed healthcare IoT during the COVID era and found that performance concerns like latency were prioritized over security and privacy in that literature. Hamid and colleagues looked at big data frameworks for pandemic detection but did not dig into how cloud computing specifically affects privacy exposure. Kaur and colleagues examined wearable sensor security but limited their scope to the wearable device ecosystem rather than the full healthcare IoT stack.
Other reviews went deeper on individual layers without connecting them. Rezapour and colleagues focused only on the fog layer. Hameed and colleagues reviewed machine learning based intrusion detection specifically. Al Khatib and colleagues covered a broad range of applications and mitigation strategies including blockchain and lightweight cryptography, but did not systematically compare how cloud or fog integration changes the risk picture. Mahmood and colleagues built a security architecture prioritization framework but concluded that many proposed solutions simply do not hold up once tested under real healthcare IoT conditions, a finding that this newer review ends up echoing independently.
The gap this paper claims to fill is the absence of a review that compares security techniques across device, edge, fog, and cloud layers at once, while also folding in AI driven analytics, which barely existed as a topic in the earlier reviews that mostly cover work published before 2023. Whether that gap fully justifies a new standalone review or could have been addressed by an update to an existing one is a fair question a reader might ask, but the authors do make a reasonable case that no prior review attempted the specific cross layer synthesis Table 1 in the paper lays out.
The six categories, and what actually goes into each one
The heart of the paper is a taxonomy sorting the 72 studies into six method categories. These are not mutually exclusive, since a single paper often combines multiple techniques, which is itself one of the review’s more interesting findings.
| Category | Studies | Share of total | Representative techniques |
|---|---|---|---|
| System architecture and computing infrastructure | 39 | 54.2% | Edge, fog, and cloud deployment models, three layer and four tier architectures, micro service composition |
| Cryptography and encryption | 33 | 45.8% | Elliptic curve cryptography, lightweight and hash based methods, quantum cryptography, differential privacy variants |
| Authentication and access control | 21 | 29.2% | Mutual authentication, three factor and multimodal biometric schemes, attribute based encryption |
| Security analysis and protocols | 21 | 29.2% | Formal security analysis, cryptanalysis, performance evaluation, simulation based testing |
| AI and data analytics | 19 | 26.4% | Machine learning and deep learning threat detection, federated learning, explainable AI for anomaly detection |
| Privacy preservation and compliance | 13 | 18.1% | Fully homomorphic encryption, anonymization, differential privacy, regulatory framework alignment |
Architecture design being the most common category makes intuitive sense once you think about it. Almost every proposed security method needs to sit somewhere, on a device, at an edge gateway, at a fog node, or in the cloud, so architectural choices show up in nearly every paper regardless of what its primary technical contribution actually is. Cryptography’s strong second place reflects the field’s continued reliance on encryption as the baseline defense, with elliptic curve cryptography favored specifically because it offers security roughly equivalent to older algorithms like RSA using dramatically smaller keys, a real advantage on devices with limited memory and battery life.
Privacy preservation coming in last at 13 studies is worth sitting with. It is not that privacy matters less to the field, the review is explicit that this is an emerging focus relative to the more established areas of cryptography and architecture. But it also shows the highest tendency of any category to combine with other techniques, appearing alongside at least one other category in 11 of its 13 studies, most often paired with cryptography and architecture design. Privacy in healthcare IoT, in other words, rarely stands alone as a technique. It gets layered on top of encryption and deployment choices rather than solved independently, which tracks with how privacy engineering tends to work in practice everywhere, not just in this field.
How the categories overlap
The cross category analysis in the paper, built from a co-occurrence map across the six taxonomy groups, surfaces a pattern that a simple count by category would miss entirely. Architecture design and cryptography co-occur in 26 of the 39 architecture studies, which the authors read as confirmation that architectural solutions rarely operate in isolation from encryption. AI and machine learning show the strongest coupling with architecture of any pairing, appearing together in 15 of 19 AI studies, suggesting that intelligent analytics in this field are mostly built for distributed edge or fog deployments rather than centralized systems, which lines up with the latency requirements discussed earlier.
Security analysis and protocols appear consistently across every other category too, which the authors interpret as reflecting a maturing field where formal verification and performance testing are treated as a standard final step rather than an optional add on. That is a small but genuinely useful signal for anyone building a new healthcare IoT security method. If your paper or your product skips the formal or simulated evaluation step, you are now an outlier relative to how this field typically validates its own claims.
What changed in the most recent studies
The review pays particular attention to studies from 2024 and 2025, treating them as evidence of where the field is actually headed rather than where it has been. Several specific results stand out. Islam and colleagues propose a hybrid fog edge architecture with end to end encryption that the review credits with a 70 percent latency reduction and a 60 percent bandwidth saving compared to cloud only approaches. Samriya and colleagues introduce an explainable AI framework for anomaly detection, described using a radial Boltzmann Gaussian temporal fuzzy network, reaching 98 percent detection accuracy while providing the kind of interpretable output that regulatory frameworks increasingly demand. Zhang and colleagues integrate 5G networks with authentication protocols across a hybrid edge fog cloud architecture, reporting 30 percent lower transmission costs and sub millisecond computational overhead. Alshuhail and colleagues report 95.4 percent detection accuracy for fall and cardiac events using edge based AI with sensor fusion.
Taken as a group, these recent studies point toward five specific directions the review flags as emerging. Integration of 5G networks for faster, lower overhead authentication. Adoption of explainable AI specifically to satisfy privacy and regulatory transparency requirements rather than purely for accuracy gains. Named data networking combined with edge computing for more efficient medical data retrieval. A mist computing layer sitting below fog for applications that need response times under 10 milliseconds. And standardization efforts tied to the European Health Data Space, which aims to establish semantic interoperability across health data systems in the European Union.
Explainable AI as a compliance tool, not just an accuracy tool
One thread that runs quietly through several of these recent studies deserves more attention than a single bullet point gives it. Explainable AI shows up in this review not primarily as a way to make models more accurate, but as a way to make security decisions defensible to regulators and clinicians. The General Data Protection Regulation includes something close to a right to explanation, and the Health Insurance Portability and Accountability Act has documentation requirements that a black box anomaly detector cannot easily satisfy. When a system flags a device or a data access pattern as suspicious, someone eventually has to be able to explain why, both to a compliance officer and potentially to the patient whose data triggered the flag. That is a genuinely different design constraint than optimizing for detection accuracy alone, and it is one that healthcare specifically imposes in a way that, say, a retail fraud detection system does not face nearly as strictly.
Where the field keeps stumbling
The review does not stop at cataloguing what works. It builds a separate taxonomy of nine recurring limitation categories drawn from the same 72 studies, and this is arguably the more useful half of the paper for anyone actually trying to deploy something. Scalability and dynamic adaptation is the most frequently cited limitation, appearing in 17 studies, followed by high resource requirements in 15 studies and real world testing and validation gaps in 12 studies. Vulnerability to new threats, usability and security tradeoffs, and deployment and maintenance issues cluster around 9 to 10 studies each. Lack of standardization across healthcare IoT security solutions is the least common concern at just one study, though the authors argue this understates its real importance rather than reflecting genuine lack of urgency.
| Limitation category | Studies citing it | What it typically means in practice |
|---|---|---|
| Scalability and dynamic adaptation | 17 | A method that works for a pilot deployment of a few dozen devices does not necessarily hold up across a hospital network of thousands |
| High resource requirements | 15 | Processing power, memory, and battery demands exceed what many actual wearable or implanted devices can supply |
| Real world testing and validation | 12 | Many proposed methods are validated in simulation or a controlled lab setting rather than a live clinical environment |
| Vulnerability to new threats | 10 | Solutions considered secure at publication time can become inadequate as attack techniques evolve |
| Usability and security tradeoffs | 9 | Stronger security measures often slow down or complicate access for clinicians who need fast, low friction data access |
| Deployment and maintenance issues | 9 | Theoretically sound solutions often lack the operational tooling needed for sustained use in real hospital infrastructure |
Mapping these nine limitation categories back against the six method categories, using the paper’s own cross tabulation, shows that architecture and cryptography research engage with the widest range of limitations, which makes sense given how frequently those two categories appear across the corpus. Scalability and deployment issues in particular show up as concerns across nearly every technique family rather than being specific to any one method, which suggests these are closer to structural problems with how healthcare IoT gets built than problems any single cryptographic or architectural innovation is likely to solve on its own.
The gap between a paper and a hospital ward
Real world validation, or the lack of it
This is the part of the review that deserves the most scrutiny from anyone thinking about actually deploying one of these methods. Twelve of the 72 studies were explicitly flagged for insufficient real world testing and validation, relying instead on simulation or controlled lab conditions that do not capture the messiness of an actual hospital network. A simulated network does not have nurses who forget to update firmware, does not have interference from dozens of other wireless medical devices operating in the same physical space, and does not have the intermittent connectivity that a rural clinic or a moving ambulance actually experiences.
The recent 2024 and 2025 studies show some improvement here. Islam and colleagues combined simulation with proof of concept deployments in actual healthcare facilities. Alshuhail and colleagues report field validation in distributed healthcare settings, which the review calls a rare and valuable form of evidence given how uncommon genuine field trials are in this literature. But the review is honest that even these newer efforts run for months rather than years, cover dozens rather than thousands of devices, and stop well short of the kind of long term, large scale deployment data that would let a hospital system administrator make a fully informed adoption decision.
There is also a structural reason this gap is hard to close, one the review gestures at without fully spelling out. Testing a healthcare security method adversarially, the way security researchers test defenses in other domains through red team exercises and deliberately induced failures, runs into real ethical and safety constraints when the system under test is connected to actual patients. You cannot casually simulate a denial of service attack against a live cardiac monitor to see what happens. That constraint is entirely reasonable from a patient safety standpoint, but it also means healthcare IoT security research will likely always trail behind fields like financial cybersecurity in the rigor of its real world adversarial validation, for defensible reasons that are unlikely to change.
Regulatory and safety context
The regulatory backdrop matters here too. The review repeatedly references the Health Insurance Portability and Accountability Act in the United States and the General Data Protection Regulation in the European Union as the two frameworks most security methods are designed to satisfy. More recent work also references the European Health Data Space, an initiative aimed at standardizing semantic interoperability across EU health data systems under ISO/IEC 21823-3:2021, which the review notes could take years to fully implement given the ecosystem level coordination it requires across 27 member states. None of this changes what a specific device does technically, but it shapes which technical approaches researchers prioritize, since a method that cannot demonstrate compliance with these frameworks is unlikely to see real deployment regardless of its technical merits.
Honest limitations, including the review’s own
Every systematic review inherits limitations from its search strategy, and this one is candid about several of them. The search was restricted to English language studies, which means relevant work published in other languages was excluded by design, not by quality. Grey literature such as industry white papers and unpublished technical reports was excluded entirely, which likely means some genuinely deployed but unpublished security practices from device manufacturers are simply invisible to this review. The authors also note explicitly that the 72 studies mostly examine healthcare IoT applications in a broad, generalized context rather than tying methods to specific diseases or device types, which limits how directly the findings translate to, say, cardiac monitoring specifically versus fall detection specifically.
Sample size is worth naming plainly here too. Seventy two studies is a reasonable number for a systematic review in a focused subfield, and the search process behind it, moving from 3463 initial records down through several screening stages, is more transparent than many reviews manage. But 72 is still a small enough number that individual outlier studies, particularly the handful of high profile 2024 and 2025 papers reporting striking figures like 70 percent latency reductions or 98 percent detection accuracy, can shape the review’s narrative about where the field is heading more than their number alone might suggest they should. Readers should treat those headline figures as promising early results from individual studies rather than as settled, broadly replicated findings.
There is also the matter of the internal numbering discrepancies mentioned earlier, between the abstract’s category counts and the body text’s category counts, and between the reported paper counts at different stages of the screening funnel. None of these appear to reflect any attempt to mislead, they read as the kind of small inconsistency that creeps into a long manuscript across revisions. But for a document whose entire authority rests on the precision of its counting, it is a fair thing for a careful reader to notice and to factor into how much weight they put on any single number the paper reports.
What this means if you are actually building something
Step back from the individual categories and a fairly clear practical takeaway emerges. If you are choosing where to invest security effort in a healthcare IoT deployment, the paper’s own cross tabulation suggests starting with architecture and cryptography together, since that pairing shows the strongest track record and the most co-occurrence in the literature, then layering authentication and privacy preservation on top rather than treating any single technique as sufficient on its own. The review’s finding that privacy preservation almost never appears alone, but consistently combines with cryptography and architecture, is itself a useful design signal. Nobody in this literature is shipping privacy as a standalone bolt on feature, and a team that tries to treat it that way is working against the grain of what has actually been shown to work.
The other practical signal worth taking seriously is the resource constraint problem. Fifteen of the 72 studies flag high resource requirements as a limitation, and that number should weigh heavily on anyone evaluating a proposed security method for an actual wearable or implanted device rather than a lab prototype. A cryptographic scheme that performs beautifully on a benchmark server is not automatically appropriate for a device that has to run for a year on a single battery. Elliptic curve cryptography earns its recurring appearance in this review specifically because it manages to offer strong security within those constraints, and that specific tradeoff, security strength against resource footprint, is probably the single most consistently recurring tension across the entire body of literature this review covers.
Conclusion
The real contribution of this review is not any single statistic, it is the map it draws across a genuinely fragmented literature. Healthcare IoT security research has been happening in silos for years, with one group of researchers focused on wireless threats, another on wearable devices, another on fog computing specifically, and almost none of them talking to each other across those boundaries. By pulling 72 studies into one taxonomy spanning six method categories and cross referencing them against nine recurring limitations, this paper gives anyone entering the field a starting map that simply did not exist before in this form.
The conceptual shift worth carrying forward is the recognition that security in this domain is not a single layer problem. A method that only addresses encryption without considering where it sits architecturally, or an authentication scheme that ignores the resource constraints of the device it protects, is solving half a problem while leaving the other half exposed. The review’s cross category co-occurrence analysis makes this concrete rather than abstract, showing exactly which technique pairings the field has already converged on and which remain underexplored.
This synthesis is not limited to healthcare specifically, even though healthcare is where the stakes are highest. Any resource constrained IoT deployment facing the same cloud, edge, and fog tradeoffs, whether in industrial monitoring, smart agriculture, or environmental sensing, faces a structurally similar set of decisions about where to place computation and how to layer defenses across distributed nodes. The specific regulatory pressures differ, but the architectural tension does not.
What remains genuinely unresolved, and the review is refreshingly direct about this, is the gap between what gets published and what gets deployed at scale in a real hospital system over years rather than months. Twelve studies flagged for inadequate real world testing, fifteen flagged for resource demands that exceed actual device capabilities, and nine flagged for deployment and maintenance issues collectively describe a field that is still closer to proof of concept than to mature, field tested infrastructure. That is not a criticism unique to this subfield of computer science, most emerging security research looks like this before it matures, but it is a caution worth repeating every time a headline statistic like a 98 percent detection accuracy or a 70 percent latency reduction gets cited without the surrounding context of how limited the testing conditions behind that number actually were.
The next time a vendor pitches a healthcare IoT security product on the strength of a single impressive benchmark, the useful question this review equips a reader to ask is not whether the number is real, but which of these six categories the product actually falls into, which of the nine limitation categories it has genuinely addressed, and whether anyone has tested it somewhere that looks like an actual hospital rather than a lab.
Frequently asked questions
What is healthcare IoT and why does it need different security than regular IoT
Healthcare IoT refers to interconnected medical devices such as wearable sensors, implantable devices, and remote monitoring tools that collect and transmit patient health data. It needs different security consideration than general IoT because the data involved is highly sensitive, the devices are often severely resource constrained in terms of battery and processing power, and failures can directly affect patient safety rather than just data privacy.
How many studies did this systematic review actually analyze
The review screened 3463 initial records from nine digital libraries down to 72 peer reviewed studies published between 2015 and October 2025, following a structured screening process that removed duplicates, excluded secondary studies such as other reviews, and applied a quality assessment checklist based on five criteria.
What are the six main categories of security methods identified in the review
The six categories are system architecture and computing infrastructure, which appeared in the most studies at 39, cryptography and encryption at 33 studies, authentication and access control at 21 studies, security analysis and protocols also at 21 studies, AI and data analytics at 19 studies, and privacy preservation and compliance at 13 studies, the least represented category.
Why does the review say cryptography and architecture design are so closely linked
The review’s cross category analysis found that architecture design studies employ cryptography in 26 of 39 cases, showing that architectural decisions about where data gets processed rarely stand apart from decisions about how that data gets encrypted. The authors read this as confirmation that effective healthcare IoT security requires integrated rather than single method solutions.
What gaps remain unresolved according to this research
The review identifies nine recurring limitation categories, with scalability and dynamic adaptation, high resource requirements, and insufficient real world testing and validation as the three most frequently cited. The authors also point to lightweight encryption, hardware agnostic security solutions, and long term field deployment studies as priorities for future research.
Is this review itself peer reviewed and where can I read it
Yes, the review by Gheida Shahrour, Aisha Junejo, and Amro Al Said Ahmad from Keele University was published in Computer Science Review, an Elsevier journal, in 2026, and it is available as an open access article under a Creative Commons license through the journal’s DOI link.
Read the full open access systematic review for the complete taxonomy tables and reference list.
Read the paper (DOI, open access) Zotero, the reference tool used in this reviewThe complete open access article, including the full 72 study reference list and every taxonomy table referenced above, is available through its DOI at Elsevier’s Computer Science Review, published under a Creative Commons Attribution license.
This analysis is based on the published paper and an independent evaluation of its claims.