Survey of Machine Learning Based Intrusion Detection Methods for Internet of Medical Things

1. Introduction

• IoMT sensors collect health data and send it to remote servers for AI-assisted analysis by physicians; applications include continuous monitoring and chronic-condition management.Examples include insulin pumps, pacemakers, and Deep Brain Implants.Source: §1 · pp. 1–2
• IoMT can support earlier disease identification, more efficient treatment, remote access to medical data, and care at home.The paper also describes possible reductions in medical errors, hospital visits, costs, and resource use.Source: §1 · p. 2
• Wireless transmission and sensitive health data expose IoMT to attacks that can compromise confidentiality, integrity, and availability, with potentially fatal consequences for patients.The paper also notes that limited sensor computation and storage, emergency access needs, and evolving attack vectors constrain conventional and lightweight security measures.Source: §1 · p. 2
• The paper motivates ML because IoMT data can support learning normal behavior and detecting anomalies, while deep learning can automate feature extraction and ML can detect zero-day attacks.The authors also argue that ML may suit IoMT security requirements and emergencies better than traditional access-control methods.Source: §1 · p. 2
• The survey asks about IoMT architecture, security requirements and threats, layer-specific ML solutions, their advantages and disadvantages, and the datasets used to train and test models.It also outlines the paper’s sections on threats, IDS, ML methods, layer-specific solutions, and challenges.Source: §1 · pp. 2–3

2. RELATED WORK

• The paper contrasts its broad ML-focused comparison with prior reviews that mention ML briefly, emphasizing solution advantages, disadvantages, approaches, and datasets.The authors point to Table 3 for comparisons with existing surveys.Source: §2 · p. 5, Table 3 · p. 6
• Earlier reviews cover medical-device privacy and safety [9], authentication schemes [10], malware and security criteria [11], healthcare attacks and solutions [12], WBAN protection [13], and IoMT security technologies [14].The topics and printed markers identify the distinct scopes described for those prior reviews.Source: §2 · p. 5
• The authors report that few IoMT security surveys treat ML holistically, and the closest prior survey omitted medical-server security while this work covers device, transit, and storage levels.The paper says its layer-wide review enables discussion of ML methods for IoMT security and privacy globally.Source: §2 · p. 5

3. ARCHITECTURE OF IoMT

• The survey assumes three logical IoMT layers—data acquisition, personal server, and medical server—while noting that literature also proposes other layer counts and technologies.The three-layer division is the paper’s organizing architecture, illustrated in Figure 2.Source: §3 · p. 6

3.1. Data Acquisition Layer

• Data-acquisition devices include implanted, wearable, ambient, and stationary sensors that gather biomedical and contextual signals.These devices have low-power computing, connectivity, and storage; constrained batteries, memory, and energy limit security measures and communication.Source: §3.1 · p. 6

3.2. Personal Server Layer

• Personal servers such as smartphones and laptops process and store patient data, may add context or encrypt and compress it, then forward it to medical servers.They support heterogeneous communication and node mobility, and can resend data when the medical-server link is interrupted.Source: §3.2 · p. 7

3.3. Medical Server Layer

• The medical-server layer provides centralized patient-data storage and processing, including long-term behavior analysis and access to records by doctors, patients, and pharmacy staff.It includes high-performance data centers and cloud servers, and may aggregate data into EHRs, EMRs, or prescription websites.Source: §3.3 · p. 7

4.1. Confidentiality

• Confidentiality keeps identifiable health and treatment information inaccessible to unauthorized parties during storage and communication.The stated purpose is protecting patient privacy from disclosure.Source: §4.1 · p. 7

4.2. Integrity

• Integrity ensures medical data arrive uncorrupted and are not changed by anyone other than involved clinicians, preventing incorrect treatment.Even minor changes to medication or test results may have catastrophic implications.Source: §4.2 · p. 7

4.3. Availability; 4.4. Freshness

• Availability requires uninterrupted clinical-record access and rapid emergency response; freshness prevents replay of old data and distinguishes partial from complete ordering.Strong freshness also allows delay calculation, unlike weak freshness.Source: §4.3 · p. 8, §4.4 · p. 8

4.5. Scalability

• Scalability requires functioning as device numbers grow while managing computing and storage overhead, especially when emergency response time matters.Insufficient scalability can create security flaws.Source: §4.5 · p. 8

4.6. Non-repudiation; 4.7. Authentication; 4.8. Authorization

• Non-repudiation prevents entities from denying sent or received health information, while authentication checks data sources and participant identities before exchange.Authorization then assigns permission levels for patients, physicians, or nurses accessing medical databases.Source: §4.6 · p. 8, §4.7 · p. 8, §4.8 · p. 9

4.9. Audit; 4.10. Forward Secrecy

• Auditing uses system and access logs to detect abnormal activity and possible breaches, while forward and backward secrecy restrict message access across sensor membership changes.Logs are difficult to manage in practice because medical and network equipment produce large, heterogeneous volumes.Source: §4.9 · p. 9, §4.10 · p. 9

5. IoMT SECURITY THREAT

• Single-hop IoMT depends on personal-server equipment whose failure can compromise the system, whereas multi-hop sensors also route data and bring routing vulnerabilities.Multi-hop routing permits node mobility and is described as maintaining low energy consumption during data transfer.Source: §5 · p. 9

5.1.1. Data Modification; 5.1.3. Modify the Software of the Device

• At data collection, attackers may modify patient data to influence diagnosis and medication or alter device software to perform malicious actions.A cited example is software instructing a pacemaker to send an electrical charge to the patient’s heart.Source: §5.1.1 · p. 9, §5.1.3 · p. 10

5.1.2. Drain the Battery

• Battery-drain attacks consume medical-device power and can lead to battery failure.Source: §5.1.2 · p. 9

5.1.4. Jamming Attack

• Jamming interferes with wireless radio frequencies and may interrupt all or part of the network, deliberately or unintentionally.Source: §5.1.4 · p. 10

5.1.5. Node Tampering

• Physical node tampering can expose encryption keys, enable decryption of communications, or let an attacker replace a node with one under their control.Source: §5.1.5 · p. 10

5.1.6. Data Collision Attack; 5.1.7. Exhaustion; 5.1.8. Unfairness in Allocation

• Wireless collisions cause checksum-rejected packets and retransmission energy costs; repeated collisions can exhaust resources and make incoming data missed or error-prone.The paper also connects collision and exhaustion attacks with unfairness in network allocation.Source: §5.1.6 · p. 10, §5.1.7 · p. 11, §5.1.8 · p. 11

5.2.1. Eavesdropping

• Wireless eavesdropping can reveal physiological data and medical-device information; passive attackers listen, while active attackers impersonate friendly entities and send requests.Source: §5.2.1 · p. 11

5.2.2. Man In the Middle Attack; 5.2.5. Message Modification Attack

• Man-in-the-middle and message-modification attacks can capture communications, insert messages, or alter health data before delivery.Source: §5.2.2 · p. 11, §5.2.5 · p. 11

5.2.3. Scrambling Attacks; 5.2.4. Signaling Attacks

• Scrambling can interrupt personal devices and data transfer, while signaling attacks overload the base station during connection setup and prevent health-data forwarding.Source: §5.2.3 · p. 11, §5.2.4 · p. 11

5.2.6. Data Interception Attack; 5.2.7. Wormhole Attack

• Data interception exposes health data sent between connected devices, and wormholes replay duplicate packets at different locations through attacker-accessible relay nodes.Source: §5.2.6 · p. 11, §5.2.7 · p. 11

5.2.8. Denial of Service Attack (DoS)

• Denial-of-service attacks interrupt systems or networks, with distributed DoS originating from multiple distributed sources.Source: §5.2.8 · p. 12

5.2.9. Hello Flood Attack; 5.2.10. Sinkhole Attack

• Hello-flood and sinkhole attacks deceive routing nodes, respectively by appearing to be a neighbor or the best route, so packets may be misdirected or prevented from reaching destinations.Source: §5.2.9 · p. 12, §5.2.10 · p. 12

5.2.11. Replaying Attack; 5.2.12. Homing Attack; 5.2.13. Data Flooding Attack

• Replay attacks resend intercepted communications, homing scans seek key managers or cluster heads, and data flooding can exhaust a target server’s connection capacity.Source: §5.2.11 · p. 12, §5.2.12 · p. 12, §5.2.13 · p. 12

5.2.14. Desynchronization Attack; 5.2.15. Spoofing Attack; 5.2.16. Selective Forwarding Attack; 5.2.17. Sybil Attacks; 5.2.18. Path DoS Attack; 5.2.19. Overwhelming Sensors

• Other transmission threats include incomplete-message desynchronization, routing manipulation, selective forwarding, multiple claimed identities, traffic overload, sensor-stimulus overload, and hijacked remote reprogramming.The described outcomes include blocking data exchange, message loss, resource exhaustion, and compromised network areas.Source: §5.2.14 · p. 12, §5.2.15 · p. 12, §5.2.16 · p. 12

5.3. Attack at Storage Level

• The storage layer contains patient health, treatment, and identity information that adversaries may target.Source: §5.3 · p. 13

5.3.1. Patient’s Data Inference

• Patient-data inference combines information an attacker is authorized to access with other relevant information to recover medical records.Source: §5.3.1 · p. 13

5.3.2. Unauthorized Access

• Unauthorized access to unprotected patient data can enable attackers to retrieve or damage health information.Source: §5.3.2 · p. 13

5.3.3. Malware Attack

• Malware is network-spread code or a program used to extract, infect, or perform other attacker-directed operations; examples include viruses, spyware, and ransomware.Source: §5.3.3 · p. 13

5.3.4. Social Engineering Attacks

• Social-engineering techniques such as phishing and baiting trick users into supplying sensitive patient information to an unintended recipient.Source: §5.3.4 · p. 13

5.3.5. Location Threats

• Exposed location information from medical devices can let adversaries directly invade a person’s privacy.Source: §5.3.5 · p. 13

5.3.6. Alert Attack

• Attackers can abuse device alerts to trigger false alarms, contribute to wrong treatment or unnecessary visits, or cause genuine alerts to be ignored or disabled.Source: §5.3.6 · p. 13

5.3.7. Extortion/Blackmail

• Extortion can block access to medical data for ransom or threaten public disclosure of influential people’s medical histories unless payment is made.Source: §5.3.7 · p. 13

5.4. Type of Attack

• The section distinguishes passive from active attacks as the two broad categories of changing attack strategies.Source: §5.4 · p. 13

5.4.1. Passive Attack

• Passive attacks listen to traffic between wearable devices and remote systems, exposing device and patient data and threatening communication confidentiality and privacy (34).Exposed information can include device identifiers, telemetry, health records, names, ages, and conditions.Source: §5.4.1 · p. 13

5.4. Type of Attack

• Table 4 summarizes threats by IoMT level.Source: Table 4 · p. 14

5.4.2. Active Attack

• Active attackers can intercept and alter messages, block delivery, drain device energy, change settings, bypass treatment, or put a patient in shock (34).Source: §5.4.2 · p. 14

5.5. Attack Environment

• Attack environment is classified by adversary position as internal or external.Source: §5.5 · p. 14

5.5.1. Internal Attackers

• Internal attackers are nearby and have some network access; a legitimate user may misuse access, while proximity can also enable physical damage, information collection, or later remote attacks (13, 60).Source: §5.5.1 · p. 14

5.5.2. External Attackers

• External attackers need neither proximity to the medical device nor administrative access, and instead try to exploit system bugs or vulnerabilities remotely (13, 60).Source: §5.5.2 · p. 15

5.6.1. Physical Injury

• Compromised medical equipment can threaten patients through physical harm, including attacks motivated by political, criminal, or terrorist aims (62).The paper cites deactivation of former US Vice President Dick Cheney’s pacemaker wireless function as a precaution against hacking attempts (62).Source: §5.6.1 · p. 15

5.6.2. Financial Profits

• Attackers or rivals of medical-device vendors may seek financial profit by selling accessed medical data or blackmailing patients.Source: §5.6.2 · p. 15

5.6.3. Privacy Violation

• Medical data can reveal patient behavior and, across sufficiently large samples and device types, support patterns that risk unauthorized and unethical use.Pacemaker data can reveal physical activity history.Source: §5.6.3 · p. 15

5.6.4. Tracking

• Because medical equipment wirelessly sends health and position information to a controller, interception can let attackers track or locate patients.Source: §5.6.4 · p. 15

• An IDS automates surveillance and event analysis on an end device or network to detect attempts to compromise availability, integrity, confidentiality, or security mechanisms.Intrusions may come from remote attackers or legitimate internal users, including medical staff abusing privileges or mishandling data.Source: §6 · p. 15
• An IDS combines information sources, analysis, and response; responses may notify passively or interrupt communication actively, with interruption rather than attacker identification as its purpose.Source: §6 · p. 15
• IDS differs from firewalls and antivirus software by monitoring traffic and analyzing events for potential threats, and these mechanisms can be combined for in-depth security.Source: §6 · p. 15
• Network-based IDS monitors network packets, while host-based IDS monitors individual-device events and data sources; application-based IDS monitors application transaction logs.Host sources include operating-system events, audit trails, system logs, and medical records.Source: §6 · pp. 15–16
• Misuse detection matches events to predefined patterns and offers high accuracy but misses new or zero-day attacks; anomaly detection learns normal behavior and can detect novel attacks but risks false positives and needs substantial training data.Source: §6 · p. 16
• IDS operation may be real-time or interval-based, with centralized, fully distributed, or partially distributed architectures for monitoring, response, or hierarchical reporting.Source: §6 · p. 16

• Machine learning learns from data without explicit programming, adapts to new data, and can extract insights from large volumes, making it relevant to complex and changing IoT settings (64, 65).Source: §7 · p. 16
• Studies cited in the overview report that ML-based IDS can detect zero-day attacks and new vulnerabilities, unlike rule- and signature-based IDS limited to known attacks.Source: §7 · p. 16
• Anomaly detection learns a normal profile from person- or object-generated data and flags deviations as abnormal.Source: §7 · p. 16
• The overview identifies supervised, unsupervised, and semi-supervised learning as ML approaches for IoMT security.Source: §7 · p. 16
• Supervised learning trains on labeled input-output examples for prediction or classification; regression predicts continuous values and classification assigns discrete categories, with SVM, decision tree, random forest, Naive Bayes, and ANN examples.Source: §7 · p. 16
• Unsupervised learning finds patterns or groupings in unlabeled data, while semi-supervised learning combines labeled and unlabeled data to reduce manual labeling and build classifiers.K-means, KNN, and SOM are listed as clustering techniques; the passage says semi-supervised models can achieve greater accuracy than traditional supervised learning.Source: §7 · p. 16
• Deep learning uses layered processing to learn representations and features, can perform well on large datasets, and is presented as suited to IoMT’s large medical-data volumes.Examples include supervised CNNs, unsupervised deep autoencoders, and hybrid ensembles of learning networks.Source: §7 · pp. 16–17

8.1. ML for Data Collection Level Security

• TPR = 0.914, FPR = 0.101, and AUC = 0.947 were the best reported Cardiwell results for detecting and preventing cyberattacks against cardiac implants.Cardiwell uses one-class SVM in its sixth security layer; its test set included 775 benign and 28 expert-generated malicious commands, and the authors attributed ineffective later layers to limited data.Source: §8.1 · p. 17
• Collection-level studies also use Markov models for ECG and biosensor anomalies, LSTM for deep-brain-implant signal deviations, and ML frameworks for broader smart healthcare systems.The ECG study introduced 5% and 10% attacks and reported high detection rate and TPR; the WBAN method reported 100% TPR and 5.2% FAR, while the smart healthcare framework reported 91% accuracy and 90% F1-score.Source: §8.1 · pp. 17–19
• 98% success rate for detecting a single overdose attack was reported with nonlinear SVM, while MLP achieved 93.98% accuracy for classifying glucose measurements as genuine or fake.Insulin-pump studies also use LSTM dosage thresholds with patient gesture confirmation and an unsupervised deep autoencoder for four generated attacks; the latter exceeded traditional ML methods and previous work.Source: §8.1 · p. 18
• Collection-level research concentrates on cardiac implants and insulin pumps, while the review identifies wireless gastric electrical stimulators as an uninvestigated vulnerable device class.The review also notes that some Cardiwell layers did not improve results and calls for richer datasets; the gastric device’s wireless communication and missing safeguards expose it to several attack types.Source: §8.1 · pp. 17, 19

8.2. ML for Transmission Level Security

• Transmission-level work spans device-behavior detection, network and web filtering, attack prediction, and CNN classification of healthcare network events.A DNN approach combining PCA and gray wolf optimization improved IDS accuracy by 15% and reduced learning time by 32%; another study used time-series analysis to predict DDoS attacks.Source: §8.2 · pp. 23–24
• HEKA, an ML-based IDS for personal medical devices, analyzed traffic between PMDs and smartphones across eight devices and tested four attack types, reporting 98.4% accuracy and 98% F1-score.Separately, IHSS reported 93% accuracy with two hidden layers and 90% with one.Source: §8.2 · pp. 23–24
• Distributed transmission IDS assign detection across devices, networks, and agents, with decision rules that escalate suspicious activity for further review.A mobile-agent design reported DT as the best tested network-level algorithm and used polynomial regression for device anomalies; a remote-healthcare framework assigned anomaly, misuse, or hybrid detection by sensor, smartphone, and database class.Source: §8.2 · pp. 24–25
• 99.98% detection rate, 96.35% accuracy, and up to 5.59% FAR reduction were reported for a fog-cloud ensemble IDS evaluated on the Ton-IoT dataset.The system combines NB, DT, and RF outputs with XGBoost and majority voting; EOS-ELM also outperformed ELM, OS-ELM, and ML regarding accuracy, detection rate, and FPR.Source: §8.2 · p. 25
• At transmission level, Weighted Hoeffding Tree ensembles [96] balance accuracy and overhead, while SDN CNN–LSTM [20] and LSTM–GRU [97] outperform comparator methods on reported detection measures.The Weighted Hoeffding Tree system was evaluated on NSL-KDD and ToN-IoT; the SDN control-plane model was evaluated on CICDDoS2019.Source: §8.2 · p. 30
• Federated IDS approaches support distributed learning: one protects patient-data privacy and reports high detection rates with low false positives, while hierarchical aggregation minimizes computation costs.The mobile-device system uses MIMIC data with simulated attacks; adding patients did not affect training time. Hierarchical Federated Learning aggregates models at dew servers and then in the cloud.Source: §8.2 · pp. 30–31
• An explainable Simple Recurrent Unit model with skip connections outperforms LSTM and GRU on reported metrics, reduces computation costs, and identifies basic IoT device features as influential.The model uses LIME to explain classifications and was evaluated on ToN-IoT data.Source: §8.2 · p. 31
• The review identifies centralized IDS as predominant and proposes IDS–blockchain integration as a decentralized direction, while noting scalability, energy, and interoperability challenges.Future solutions should prioritize patient privacy, interpretable and explainable models, and appropriate learning and testing using custom-designed IoMT datasets.Source: §8.2 · p. 31

8.3. ML for Storage Level Security

• For EHR access monitoring, LR and SVM achieved more than 0.90 AUC and 0.75 sensitivity against a rule-based technique [107], while collaborative filtering detected inappropriate access [108].The latter approach combines explicit and latent staff and patient features to create user fingerprints from prior access history.Source: §8.3 · p. 32
• Storage-level proposals include community-based anomaly detection of atypical user behavior [110] and cloud image segmentation with FCM and SVM, HTTPS/SSL encryption, and access controls [111].The anomaly model uses SVD to infer user communities and KNN to identify users diverging from typical communication behavior.Source: §8.3 · p. 32
• A hybrid EHR IDS combines rule-based misuse detection with voting across DT, neural-network, and k-means anomaly classifiers, using an expert system to resolve conflicts [112].It was tested with a dataset generated by monitoring the Italian EHR system and three separate attacks.Source: §8.3 · p. 32
• For EMR protection, SVM performed best on accuracy and recall for privacy incidents, while EMA detected message surges linked to denial of service [59]; the review finds integrity under-researched.Most reviewed work focused on unauthorized EHR access, and only one study addressed EMR confidentiality and availability.Source: §8.3 · p. 35

9.1. Data Collection Level Security

• Medical-device deployment may shorten battery life, require software or hardware changes, and expose the ML model to manipulation during learning or testing.The survey discusses on-device, third-party-device, and chip-integrated deployment; lightweight models are proposed as a promising research direction.Source: §9.1 · p. 35
• Medical anomalies may reflect poor communication, sensor faults, emergencies, or attacks, while some patients may be unable to decide whether anomalous behavior signals an attack.The survey also identifies effective communication and decision-making protocols as a challenge.Source: §9.1 · pp. 35–36
• Security datasets may lack representativeness, and existing IDS approaches cover restricted device sets despite the need to accommodate devices with different collection and communication methods.Modified medical datasets, healthy volunteers, and simulators each raise concerns about real-world validity or implementation.Source: §9.1 · p. 35
• Rule-based anomaly detection may outperform ML for medical attributes with clear value ranges, while ML can identify anomalies through correlations across attributes.The survey calls for comprehensive evaluation of both approaches and notes that models trained on one patient’s data may not generalize to others.Source: §9.1 · p. 36

9.2. Transmission Level Security

• Network-based IDS must account for IoMT’s distributed, mobile, dynamic, and heterogeneous nature, as well as imbalanced data and real-time processing demands.The survey highlights minority-class-aware metrics, large data volumes, detection accuracy, low latency, scalability, and hardware capacity.Source: §9.2 · p. 36
• Black-box opacity and adversarial vulnerability complicate healthcare use, while non-IoMT datasets may poorly represent its attacks and communication protocols.The survey presents explainable AI as an approach to improve transparency and identifies comprehensive IoMT datasets as difficult to obtain.Source: §9.2 · p. 36
• Centralized IDS architectures may entail single-point failure, latency, and privacy concerns; distributed deployment needs practical improvement, fog-cloud flow needs attention, and federated sharing faces adversarial risk.The survey describes fog-cloud as promising but identifies submerged data flow as an unresolved challenge.Source: §9.2 · pp. 36–37

9.3. Storage Level Security

• At medical servers, cross-institution data-format mismatch, unlabeled records, subtle single-feature EHR changes, and restricted access to medical records constrain IDS training and detection.Manual labeling may require patient interviews and leave detection not fully automated; the survey recommends further investigation of unsupervised or semi-supervised methods, particularly to reduce false positives.Source: §9.3 · p. 37

10. CONCLUSION

• The survey organizes IoMT security around data acquisition, personal server, and medical server layers, and reviews requirements, threats, and ML-based solutions.Solutions are categorized by data collection, transmission, and storage, with their advantages, disadvantages, and datasets discussed.Source: §10 · p. 37
• The survey discusses challenges and limitations across the three solution categories and aims to assess ML-based IDS under IoMT constraints.Its stated aim is to highlight ML’s ability to bring security to complex infrastructures such as IoMT and its capacity to comply with IoMT constraints.Source: §10 · p. 37
• The survey may omit recent unpublished or non-scientific developments, includes concepts that may require additional sources, and acknowledges subjective recommendations.The authors present these as limitations of the survey.Source: §10 · p. 37

11. CRediT authorship contribution statement

• Ayoub Si-ahmed is credited with methodology, investigation, and writing the original draft.The contribution statement assigns these roles to Ayoub Si-ahmed.Source: §11 · p. 37
• Mohammed Ali Al-Garadi is credited with methodology, review and editing, supervision, and project administration.The contribution statement assigns these roles to Mohammed Ali Al-Garadi.Source: §11 · p. 37
• Narhimene Boustia is credited with resources, review and editing, supervision, and project administration.The contribution statement assigns these roles to Narhimene Boustia.Source: §11 · p. 37