Exploring Authentication Protocols for Secure and Efficient Internet of Medical Things Systems

Abstract

The Internet of Medical Things (IoMT) comprises the application of traditional Internet of Things (IoT) technologies in the healthcare domain. IoMT ensures seamless data-sharing among hospitals, patients, and healthcare service providers, thereby transforming the medical environment. The adoption of IoMT technology has made it possible to provide various medical services such as chronic disease care, emergency response, and preventive treatment. However, the sensitivity of medical data and the resource limitations of IoMT devices present persistent challenges in designing authentication protocols. Our study reviews the overall architecture of the IoMT and recent studies on IoMT protocols in terms of security requirements and computational costs. In addition, this study evaluates security using formal verification tools with Scyther and SVO Logic. The security requirements include authentication, mutual authentication, confidentiality, integrity, untraceability, privacy preservation, anonymity, multi-factor authentication, session key security, forward and backward secrecy, and lightweight operation. The analysis shows that protocols satisfying a multiple security requirements tend to have higher computational costs, whereas protocols with lower computational costs often provide weaker security. This demonstrates the trade-off relationship between robust security and lightweight operation. These indicators assist in selecting protocols by balancing the allocated resources and required security for each scenario. Based on the comparative analysis and a security evaluation of the IoMT, this paper provides security guidelines for future research. Moreover, it summarizes the minimum security requirements and offers insights that practitioners can utilize in real-world settings.

1. Introduction

The rising average age of the global population is accompanied by an increasing incidence of chronic disease. This trend is significantly increasing the demand for efficient healthcare services. The adoption of intelligent healthcare systems is essential if systems are to meet this demand. In this landscape, the Internet of Medical Things (IoMT) is emerging as a next-generation technology for healthcare services. The IoMT supports patient-health management through remote consultations and timely interventions. It is expected to play a significant role in improving the quality, efficiency, and sustainability of healthcare services.

First, the IoMT is transforming service delivery across both clinical and home settings. Point-of-care diagnostic tools enable clinicians to perform rapid tests in hospitals and outpatient facilities, while remote monitoring extends these benefits to home care, allowing continuous health tracking without disruption of daily life [1]. In addition, the IoMT enhances the efficiency of hospital operations and resource management by monitoring various resources, including equipment, medicines, and consumables, in real time. This enhances the efficiency of supply-chain management through intuitive status monitoring and automated ordering and linking. The IoMT provides interoperability by integrating medical devices with different standards. This allows for a consistent supply of medical data, enabling clinicians to access necessary information in real time. These capabilities enable the delivery of high-quality healthcare services such as preventive medicine, management of chronic disease, emergency response, and continuous monitoring.

However, despite these advantages, the scalability of the IoMT exposes new security vulnerabilities. Because most IoMT devices are network-connected, the attack surface is significantly expanded compared to traditional healthcare environments. Attacks on medical data go beyond simple information leaks and directly impact patient lives. These threats clearly demonstrate the need for a security framework tailored to the IoMT environment. Existing IT security systems are inadequate for the unique needs of healthcare environments and the characteristics of IoMT devices, requiring the development of an encryption strategy tailored to IoMT systems [2].

Secure and reliable data transmission is a key element supporting IoMT performance. Sensors and medical devices continuously generate sensitive health data. This data flow must simultaneously meet needs related to confidentiality, integrity, low latency, and energy efficiency. Some errors can pose threats to patient health. Furthermore, inadequate security measures to ensure authentication, confidentiality, and integrity make data exchange vulnerable, posing a serious threat to the protection of sensitive medical information [3]. Therefore, it is essential to verify the efficiency and security of IoMT communication protocols. The main contributions of the paper are as follows:

(i)  

Conducting systematic and objective comparative analysis of recent IoMT security protocols to quantitatively evaluate their performance and security metrics.

(ii) 

Verifying the recent IoMT security protocols to derive essential security requirements for IoMT environments.

(iii)

Providing security guidelines for future research based on the results of comparative analysis and security assessment.

Section 2 describes IoT, IoMT, and IoMT communications. Section 3 analyzes recent research and conducts an objective evaluation. Section 4 formally verifies the proposed protocol using SVO Logic and Scyther. Section 5 discusses security requirements and safety, and Section 6 concludes this work.

2. Background

The IoMT has evolved in recent years through the integration of IoT technology into medical device systems and services. While the general IoT connects common objects such as home appliances and vehicles, the IoMT specifically links clinical devices that monitor vital signs and administer treatments [4]. This evolution has been driven by advances in low-power wireless communication and edge computing technologies, which hospitals and healthcare institutions have adopted to enhance service quality and accessibility [5].

2.1. IoT and IoMT

Figure 1 shows IoMT device classification. The IoT interconnects distinct physical entities, enabling embedded sensors and software to exchange data with edge and cloud platforms. Extending these principles into the clinical domain, the IoMT operates within care workflows to enable real-time monitoring, remote patient management, and early detection of anomalies, thereby improving patient outcomes through continuous monitoring, personalized treatment, and telemedicine [6,7]. The IoMT encompasses patient-worn devices (e.g., smartwatches, biosensor patches), hospital-deployed assets (e.g., smart beds, infusion pumps), and implantable systems that stream remote telemetry or deliver closed-loop therapies (e.g., pacemakers, neurostimulators) [8]. The IoMT sector continues to expand as companies consistently release specialized sensors and advanced monitoring tools. Unlike the general-purpose IoT, the IoMT handles sensitive health data, making robust security essential.

Figure 1. Classification of IoMT devices.

IoMT devices can fall into two main categories: Implantable Medical Devices (IMDs) and Internet of Wearable Devices (IoWDs) [9]. IMDs primarily support long-term monitoring or treatment by directly interfacing with human tissue, whereas IoWDs operate externally to collect and transmit physiological data [10,11].

Cardiovascular IMDs: Implantable cardioverter defibrillators (ICDs) detect and correct arrhythmias [12]. Left ventricular assist devices (LVADs) help maintain blood circulation in patients with severe heart failure [13].

Neurological IMDs: Deep brain stimulators (DBS) send electrical impulses to targeted brain regions to treat conditions such as Parkinson’s disease and epilepsy. Clinicians use spinal cord stimulators (SCS) to manage chronic pain. Vagus nerve stimulators (VNS) assist in managing seizures and mood disorders [14,15,16].

Metabolic and Endocrine IMDs: Implantable insulin pumps regulate blood glucose in diabetic patients [17,18].

Respiratory and Pulmonary IMDs: Diaphragm stimulators aid patients with respiratory conditions. Implantable airway sensors monitor airflow and detect abnormalities [19,20].

The use of IMDs involves challenges, including limited battery life, vulnerabilities associated with wireless communication interfaces, and risks to patients’ data privacy. The advancement of IMDs depends on reliable energy management, secure low-power communication, and compliance with healthcare safety and cybersecurity requirements. These factors remain critical challenges throughout the design, certification, and deployment of IMDs [21,22].

IoWDs function externally as a noninvasive alternative, collecting physiological data for continuous, near-real-time monitoring. They transmit this data to clinical information systems to support preventive care, long-term management of chronic conditions, and remote oversight. This process provides patients with timely feedback and reduces reliance on in-person visits [10].

Vital-Sign-Monitoring Wearables: Devices such as smartwatches and fitness trackers measure heart rate. They also track oxygen saturation (SpO₂), body temperature, and sleep patterns. Wearables equipped with ECG functions detect irregular heart activity [23].

Glucose-Monitoring Wearables: Continuous glucose monitoring (CGM) sensors measure blood glucose levels. They provide real-time feedback to diabetic patients [24].

Smart Clothing and Adhesive Health Patches: ECG-enabled garments, such as smart shirts, monitor cardiovascular activity. Smart patches measure hydration, detect temperature variations, and analyze sweat composition [25,26].

Neurological Wearables: Brain–computer interface (BCI) devices analyze brain activity to support cognitive training and neurotherapy [27].

Although IoWDs are noninvasive, they present challenges, most notably in measurement accuracy, which varies depending on wearing conditions and device-specific characteristics. Furthermore, security threats such as data leakage and tampering, which can directly impact patient safety, must also be addressed. In this context, IoMT systems continuously generate vast amounts of patient-specific clinical data. To manage the complexity of IoMT systems, a layered architecture has been adopted. While various architectures exist, their components can be categorized into three core layers: perception, network, and application [28,29].

Figure 2 shows the hierarchical architecture of the IoMT. Patients access medical devices through the perception layer. This layer collects data and transmits it to the application layer via the network layer. The application layer stores the data and preprocesses it so that medical professionals can effectively utilize it.

Figure 2. Layered architecture of the IoMT.

The perception layer handles all components that capture medical data at the source. It includes wearable health monitors, implantable devices, and hospital-grade diagnostic machines. These instruments collect raw physiological data, such as heart rate, oxygen saturation, glucose concentration, and other vital indicators. Wearable sensors play a central role in this layer. Devices such as smartwatches and biosensor patches continuously track the condition of a patient without disrupting daily routines. In addition to acquisition, many devices perform basic processing by filtering noise, compressing signals, and detecting abnormalities before transferring the processed information to the network layer [29].

The network layer is the intermediate layer connecting the perception layer and the application layer in the IoMT architecture. It securely and quickly transmits data collected by sensors to hospital servers, cloud platforms, or healthcare service providers. The primary purpose of this layer is to ensure data confidentiality, integrity, and availability during transmission while maintaining the real-time performance essential in healthcare environments and ensuring seamless connectivity. These functions are essential for ensuring uninterrupted data transmission, especially in life-threatening situations. In addition, edge computing devices are deployed at the network layer to reduce communication delays with cloud servers and enable immediate local processing of urgent data [30].

As the upper layer, the application layer aggregates data received from the network layer and delivers it to healthcare providers. This layer enables remote monitoring and control in medical settings, facilitates real-time assessment of a patient’s condition, and supports physicians in making data-driven diagnoses and treatment decisions. User interfaces, including the software and applications used at the application layer, play a critical role in managing the increasing complexity of system administration [31].

2.2. IoMT Communication Protocols

IoMT systems employ multiple communication protocols to connect devices, networks, and applications. Each component requires a suitable method for data transmission. At the perception layer, where data collection occurs, short-range protocols are common. RFID tags track medical equipment in hospitals. They are small and inexpensive and do not require batteries. A reader emits a signal, and the tag returns the information. NFC operates in a similar way but requires close contact (within a few centimeters). Bluetooth Low Energy (BLE) is widely used in wearable devices because it minimizes power consumption. Most fitness trackers and health monitors rely on BLE to connect with smartphones [32]. ZigBee conserves energy and supports mesh networking, making it suitable for large-scale IoMT integration [33]. For longer distances, Wi-Fi is frequently deployed in hospitals due to its high transmission speed, although it consumes more power. Remote monitoring systems often adopt cellular networks such as 4G and 5G, especially for patients at home [34]. These connections enable clinicians to observe a patient’s condition without in-person visits. At the application layer, different protocols manage collected data. MQTT provides lightweight many-to-many communication through a publish–subscribe model. It reduces network overhead and supports three quality-of-service (QoS) levels for varying reliability requirements [35]. Constrained Application Protocol (CoAP) serves as another option and is particularly effective for devices with limited processing capacity [36]. Healthcare systems also apply standards such as Health Level 7 (HL7) to ensure consistent interpretation of medical information across institutions [37]. Standardization plays a critical role in enabling interoperability among hospitals and healthcare providers.

Protocol selection depends on device power capacity, data volume, and security requirements. Security remains a central concern due to the sensitivity of medical data. Each system layer must apply strong encryption and authentication mechanisms to guarantee secure access. An appropriate combination of these protocols enables real-time monitoring, health-trend analysis, and remote care delivery while meeting strict regulatory standards.

3. Recent Research

3.1. Literature Review

In this section, we review recent research on the IoMT. The papers cover the architecture of the IoMT, future directions, security requirements, and the authentication protocol or enhanced authentication protocol. A description of each paper is provided below, and Table 1 summarize these results.

Table 1. Summary.

Type	Ref.	Purpose	Description	Advantages	Challenges
IoMT Survey	[38]	- Description of the challenges associated with IoMT	- Integrates new-generation tech. (such as ML, blockchain, fog, and edge computing)	- Enables analysis of medical data using machine learning - Achieves low latency and efficient data processing through fog and edge computing	- Mobility - Security and privacy - Interoperability and scalability - Real-time operation - Low-power operation
IoMT Survey	[39]	- Design of an IoMT security framework and application of an e-healthcare system	- Investigates PUF, blockchain, AI, and SDN - Validated through three case studies evaluating authentication, security, performance, and data collection	- Proposes an IoMT architecture - Applies new technology for security and performance - Maps real-life applicability - Conducts experimental validation through case studies	- Difficulty in activating SDN - Black-box problem in AI (XAI) - Blockchain scalability
IoMT Survey	[40]	- Design of a web-based security-assessment framework	- Uses an ontology- and scenario-based approach to create a web-based security-assessment framework (IoMT-SAF) - Supports the evaluation of protection and deterrence capabilities	- Utilizes real-world security-threat cases and cyberattack data - Evaluates framework performance using the CVE list	- Security-profile definition is lengthy and complex
IoMT Survey	[41]	- Research on recent advances in IoMT security	- Proposes a three-stage IoMT security framework addressing data collection, data in transit, and data storage	- Analyzes IoMT security requirements - Proposes an IoMT security framework	- Blockchain scalability - Securing remote setup and providing alternative access methods
IoMT Survey	[42]	- Review of IoMT security models and various key algorithms	- Discusses security requirements of the IoMT model - Discusses symmetric-key algorithms - Discusses keyless algorithms	- Identifies security weaknesses in IoMT systems- Details methods to accomplish end-to-end security - Presents mechanisms that protect privacy and anonymity	- High infrastructure cost - Strain on existing networks - Lack of standardization
IoMT Survey	[43]	- Survey of IoMT security requirements, design issues, methods, and future trends	- Analyzes IoMT background and security threats - Investigation of security requirements - Reviews design challenges associated with the IoMT environment - Presents various security technologies	- Offers detailed classification of device sensors associated with the IoMT - Presents security requirements - Investigates security techniques	- Security and privacy issues - Design complexity - Network-connectivity limitations
Protocol	[44]	- Lightweight authentication and key-agreement protocol	- Introduces a lightweight authenticated key-agreement scheme for IoMT systems - Verified security via Scyther - Outperforms existing methods in cost and security	- Reduces encryption overhead through Hashing and XOR - Performance optimization	- Persistent threats and security/privacy challenges
Protocol	[45]	- Proposes a lightweight mutual-authentication protocol using blockchain	- Employs ECC and CRT for efficient identity verification - Integrates NFTs to provide immutable and verifiable identity records on the blockchain	- Verified against replay and MITM attacks via AVISPA - In performance evaluation, low communication and storage costs	- Risk of device hijacking - Vulnerabilities in centralized identity management - Residual delays in NFT registration
Protocol	[46]	- Proposes a lightweight authentication protocol based on post-quantum cryptography	- Replaces current authentication methods used in the IoMT, which rely on simple passwords and lack additional layers of protection, posing a risk of data breaches. - Introduces a lightweight authentication protocol based on post-quantum cryptography	- Strong security against quantum attacks - Efficient key generation to support the performance and scalability of the IoMT device	- Entity verification - Authentication of medical devices
Protocol	[47]	- Proposes an ultra-lightweight and secure RFID authentication scheme	- Uses the solutions of homogeneous linear equations as keys - Minimizes tag costs and allows tags to encrypt and decrypt data through lightweight computations	- Minimizes costs - Enables mutual authentication - Suitable for emergency-response applications	- Limited applicability to realistic medical scenarios - High scanning cost
Protocol	[48]	- Privacy-protection authentication-management protocol	- Employs three-factor authentication to ensure user identity is verified on login. - Employs the Chebyshev chaotic map to support the authentication process and key security	- Verified via BAN logic - Resists attacks and results in various security attributes.	- Lightweight blockchain limitations - Need for a reliable authentication and verification mechanism without a TA - Lack of research on quantum-resistant cryptography algorithms
Protocol	[49]	- Proposed authentication and key management based on blockchain	- Need for a secure authentication key-management protocol leveraging tamper-resistant and decentralized blockchain mechanisms to secure communications in IoMT environments.	- Robust against attacks (replay, MITM, impersonation, ESL attacks, etc.) - Formally verified for security using AVISPA.	- Not mentioned in this paper.
Protocol	[50]	- Proposes a multifactor user-authentication protocol using blockchain and elliptic curve cryptography (ECC)	- Implements a multi-authentication protocol based on blockchain and ECC. - Demonstrates resistance to various attacks in security verification	- Low computational cost - Enhanced security and computational performance	- High cost due to blockchain usage - Higher communication overhead.
Protocol	[51]	- Analysis of Chen et al. [52] authentication protocol - Improves on Chen et al.’s authentication protocol	- Addresses the shortcomings of Chen et al. with an improved authentication protocol using elliptic curve discrete-logarithms, encryption and hashing methods.	- Robust against attacks (replay, MITM, impersonation, ESL attacks, etc.) - Formally verified for security using AVISPA.	- Limited application of emerging technologies, machine learning, quantum cryptography, and blockchain technology
Protocol	[53]	- User-authentication protocol (3ECAP)	- Uses three-factor authentication (passwords, biometrics, smart cards) and mitigates privilege-escalation attacks with Merkle tree-based access control.	- Verified security via ProVerif - Resistant to attacks (replay, MITM, Sensor hijacking etc.)	- Not mentioned in this paper.
Authentication framework	[54]	- Lightweight two-factor authentication framework (L2FAK)	- Addresses gap: existing approaches fail to address several security vulnerabilities, such as user and gateway tampering	- Improves transmission efficiency and reduces overhead compared to existing methods. - Enhances authentication accuracy in medical applications using federated learning.	- Not mentioned in this paper.

According to Askar et al. [38], the IoMT is a concept that uses IoT technology to improve healthcare systems to make them smarter and more proactive. The IoMT can integrate new technologies such as ML, Blockchain, Fog, and edge computing to provide benefits such as faster treatment, improved communication, and cost reduction. This research analyzes analyzes various IoMT technologies and solutions built on these paradigms and presents possible directions for future development and applications.

Razdan et al. [39] noted that IoMT-based healthcare systems improve the quality of life of all stakeholders, not just patients. However, there are challenges such as power consumption, energy efficiency, security and privacy, high data-transmission rates, and low latency. To solve these problems, researchers are developing technologies that integrate ML, blockchain, fog, and edge computing, and emphasize that these technologies are essential if we are to improve the performance and enhance the security of IoMT healthcare systems. This paper analyzes the current status and potential future applications of IoMT systems that leverage the latest technologies and suggests future research directions and innovative application cases to advance the healthcare industry.

Ghubaish et al. [41] find that the rapid development of micro-computing, mini-hardware manufacturing, and M2M communication has made it possible to reconfigure many networking applications with new IoT solutions. An IoMT system can remotely monitor patients with chronic diseases. Therefore, the IoMT can provide timely patient diagnoses that can save lives in emergency situations. However, the security of these critical systems is a major challenge facing their widespread use.

Hatzivasilis et al. [42] show that security threats are increasing because patients and healthcare professionals process healthcare data using their own devices through Bring Your Own Device (BYOD) use cases. The latest security and privacy controls in the IoMT environment aim to address this problem. On combining IoMT and CE, users can expect improved accessibility, cost reduction, rapid implementation, and improved efficiency. In conclusion, this paper presents key security-control measures to protect CE-based IoMT systems and provides practical guidelines for enhancing security and privacy.

Bhushan et al. [43] show that the use of the IoMT has brought about great changes in healthcare through the deployment of universal and inexpensive devices. However, they suggest limitations on the adoption of IoMT devices due to security and privacy issues. This paper emphasizes the importance of core security measures for securing IoMT systems and enhancing interconnectivity between healthcare domains to address these limitations. The paper identifies three principal security technologies applicable to the IoMT environment: asymmetric key algorithms, which ensure robust data protection and authentication; symmetric key algorithms, which offer fast and efficient data encryption; and keyless algorithms, which fulfill the security requirements of IoMT systems through non-traditional mechanisms.

Alsubaei et al. [40] assert that in the IoMT environment, security and privacy issues are considered serious due to the presence of various IoMT devices that transmit sensitive medical data to the cloud. Consequently, IoMT security assessments and the selection of appropriate protection measures are important, but can be difficult for users who lack security knowledge. To address this, the authors propose a security-assessment framework that can recommend security features for the IoMT and evaluate their protection and deterrence capabilities. This provides practical experience in IoMT security, promotes competition by enabling security solution providers to verify and evaluate product security, and promotes the design of IoMT solutions that reflect the security measures required by consumers.

Abdussami et al. [44] argue that sensitive data related to patient health are vulnerable to attacks. The authors propose an architecture utilizing cloud servers and edge-computing technologies suitable for local and emergency scenarios. The Provably Secured Lightweight Authenticated Key Agreement Protocol (PSLA2P) is a lightweight authentication and key-agreement protocol that can be deployed in the proposed network architecture for the modern health industry. It protects data privacy by providing anonymity, untraceability, and integrity to the patient. In this paper, we prove that the PSLA2P protocol is secure through Scyther formal verification. Through performance evaluation, we show that it is superior to other approaches in terms of computational cost, communication cost, and security features.

Qiu et al. [45] propose a lightweight mutual-authentication method using blockchain to improve privacy protection and secure communication. The protocol uses elliptic curve cryptography (ECC) and the Chinese remainder theorem (CRT) to perform identity authentication efficiently. It also uses non-fungible tokens (NFTs) to make identity information on the blockchain immutable and verifiable. To enhance security, it applies two-factor authentication by combining certificate-based verification with physically unclonable functions (PUF). Security analysis using AVISPA confirms resistance to replay attacks and man-in-the-middle attacks. Performance evaluation shows low communication and storage costs, making it usable on resource-limited devices. Ethereum-based simulations and hyperledger caliper load tests were conducted to verify practicality. However, risks such as device hijacking, vulnerabilities in centralized identity management, and delays in NFT registration remain.

According to Lo et al. [46], current authentication methods used in the IoMT in the healthcare sector rely on simple passwords. They lack additional layers of protection, posing a risk of data breaches. Furthermore, they are inadequately protected against threats posed by quantum computing. To address this issue, we propose a lightweight authentication protocol based on post-quantum cryptography. This aims to ensure the confidentiality and integrity of medical data while verifying the identities of users and devices. To defend against quantum computing attacks, lattice-based cryptography, a quantum-safe encryption method, can be utilized. The structure of lattices is based on mathematical challenges such as the shortest vector problem (SVP), closest vector problem (CVP), and learning with errors (LWE), which can serve as the foundation for future post-quantum cryptography. By applying lightweight lattice-based cryptography (LBC) to IoMT authentication protocols, the protocol can not only withstand quantum attacks, but also provide strong security against them. It also offers the key-generation efficiency critical for the performance and scalability of IoMT devices, enhances two-factor authentication, and improves user convenience during authentication.

Masud et al. [47] proposes the MASK (mutual authentication and secret key) protocol, which verifies the reliability of sensor nodes and users and defends against physical attacks using PUF. The MASK protocol guarantees key security properties such as mutual authentication, data confidentiality, integrity, anonymity, untraceability, and physical security. Performance evaluation shows that the protocol minimizes computation based on PUF, reducing the burden and keeping sensor nodes’ energy consumption and memory usage lower than they are in existing protocols. It also reduces the number of message exchanges to minimize network delay and power consumption. However, the MASK protocol has some limitations.

Miao et al. [48] propose a blockchain-based privacy-protection authentication-management protocol to address IoMT device vulnerabilities in open network environments. The proposed protocol introduces blockchain into the protocol to store device identity and authentication-key information. In addition, security is guaranteed through Chebyshev chaos maps. In this paper, security is proven through a random oracle model and BAN logic. The protocol is shown to resist attacks and result in various security properties. The results of functional comparison and performance analysis show that the proposed protocol has advantages for IoMT devices in terms of security, computational overhead, communication overhead, and storage overhead. However, the consideration is limited to the storage aspect through the application of blockchain. The response time, the efficiency of the blockchain consensus algorithm, and the method of bypassing TA to fully utilize a distributed ledger technology are not considered. Therefore, it is shown that blockchain mechanisms should be thoroughly studied in the future and that an efficient and secure authentication protocol should be designed.

Garg et al. [49] propose a new blockchain-based authentication and key-management protocol (BAKMP) for IoMT environments. The BAKMP provides secure key management between different communication entities. Authorized users can access medical data in a secure manner from the cloud server. All of the medical data are stored in a blockchain maintained by the cloud server. The BAKMP can resist security-vulnerability attacks such as replay attacks, man-in-the-middle attacks, impersonation attacks, and ephemeral secret leakage (ESL) attacks. The proposed protocol demonstrates security against various types of attacks through AVISPA. In addition, it shows better performance in terms of communication and communication costs in the security, authentication, and key-management phases compared to existing schemes.

Pradhan et al. [50] proposes a multi-authentication protocol based on blockchain and ECC. For security verification, ProVerif and BAN logic were used to demonstrate resistance against various attacks. Slither was utilized for smart contract-vulnerability analysis, and no known security vulnerabilities were found. Experimental results comparing the proposed method with existing approaches showed improved computational and communication performance, demonstrating its applicability in resource-constrained environments. However, limitations remain, such as transaction costs due to blockchain usage, higher communication overhead compared to competing protocols, and difficulties in resetting biometric authentication data if compromised. Therefore, further optimization and expansion are needed to enhance applicability in real medical environments.

Gautam et al. [51] thoroughly analyzed the authentication protocol for IoMT remote patient monitoring proposed by Chen et al. [52] and found that Chen’s protocol is vulnerable to various security threats. Chen et al. relies on a random Nonce generated by all entities for the security of the session key. Since any random Nonce can be computed by utilizing publicly transmitted messages, the protocol is vulnerable to session key attacks. The protocol proposed here addresses these shortcomings through the use of an ECC algorithm and encryption and hashing methods. The improved protocol shows resistance to various attacks such as insider attacks, replay attacks, impersonation attacks, man-in-the-middle attacks, ephemeral secret leakage attacks, and session key-disclosure attacks.

Su et al. [53] propose a new user-authentication protocol, 3ECAP, which considers both security and efficiency in the IoMT environment. To these ends, 3ECAP adopts a three-factor authentication method combining passwords, biometric information, and smart cards and prevents privilege-escalation attacks through fine-grained access control using a Merkle tree. Here’s a lightly polished version of your sentence for clarity and flow while keeping all technical details:

Furthermore, 3ECAP primarily relies on hash operations to minimize computational and communication overhead, and its security has been validated through formal analysis using ProVerif. A comparative analysis with existing authentication protocols confirmed that 3ECAP maintains low computational and communication costs while providing higher security. In particular, it allows users to update their biometric information and passwords, supports the addition of new sensor devices, and maintains both forward and backward security, which are important in the IoMT environment.

Deebak et al. [54] proposed a lightweight two-factor authentication framework (L2FAK) with privacy-preserving capability that utilizes mobile sinks for smart eHealth. In the S-IoMT environment, data-privacy protection and device security are essential factors. L2FAK utilizes mobile sinks to manage these security issues. L2FAK prevents potential threats such as privileged insider Additionally, L2FAK ensures secure mutual authentication and session key agreement, demonstrating resistance to user and gateway impersonation, privileged insider attacks, and replay attacks. L2FAK reduces computational costs and minimizes operational expenses, enhancing the performance of real-time systems. It employs lightweight computations to improve efficiency in system authentication and key agreement stages, achieving superior transmission efficiency and lower overhead compared to conventional methods.

3.2. Evaluation

Security requirements provide the foundation for evaluating the robustness of authentication protocols in IoMT environments. The core security requirements typically encompass authentication, mutual authentication, confidentiality, integrity, untraceability, privacy preservation, anonymity, multi-factor authentication, session key security, forward/backward secrecy, and lightweight operation. In addition, advanced requirements—including quantum resistance and emergency response mechanisms—are becoming increasingly important in healthcare scenarios, where the protection of sensitive medical data and the capacity for timely response to urgent situations are critical.

As shown in Table 2, most existing protocols consistently support authentication, integrity, and confidentiality, which are regarded as the fundamental security properties. However, only a limited number of protocols implement mutual authentication, indicating that many designs still rely on one-way authentication, in which the server verifies the user but the user cannot validate the server. Such asymmetry increases susceptibility to phishing and man-in-the-middle attacks. Consequently, achieving two-way trust through mutual authentication is indispensable for practical and secure deployment.

Table 2. Security requirements supported by each protocol [44,45,46,47,48,49,50,51,53,54].

Security Requirement	Abdussami  et al. [44]	Qiu  et al. [45]	Lo  et al. [46]	Masud  et al. [47]	Miao  et al. [48]	Garg  et al. [49]	Pradhan  et al. [50]	Gautam  et al. [51]	Su  et al. [53]	Deebak  et al. [54]
Authentication ✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Mutual Authentication ✓	✓	×	×	✓	✓	✓	✓	×	×	×
Confidentiality ✓	×	×	✓	✓	✓	×	✓	✓	✓	✓
Integrity ✓	✓	×	✓	✓	✓	×	✓	✓	✓	✓
Untraceability	×	✓	×	✓	✓	✓	×	×	✓	✓
Privacy Preservation ✓	×	×	×	×	×	×	×	✓	×	✓
Anonymity	✓	✓	×	✓	✓	✓	×	×	✓	✓
Multi-Factor Authentication	×	×	×	×	✓	×	✓	×	×	✓
Freshness ✓	✓	×	×	×	✓	✓	✓	✓	✓	×
Secure Session Key ✓	✓	×	✓	✓	✓	✓	✓	✓	✓	✓
Forward/Backward Secrecy ✓	✓	×	×	×	✓	×	×	✓	×	×
Lightweight Operation ✓	×	×	✓	✓	✓	✓	×	✓	✓	✓
Post-Quantum Security	×	×	✓	×	×	×	×	×	×	×
Emergency	✓	×	×	×	×	×	×	×	✓	✓

✓: Support, ×: Not Support.

The elements listed under Security Requirement in Table 2 represent the minimum recommended attributes tailored for IoMT scenarios. The essential security elements that must be satisfied include authentication, confidentiality, and integrity. In addition, considering the characteristics of IoMT devices, secure session key, lightweight operation, privacy preservation, mutual authentication, and freshness are also included. These attributes can be more practically beneficial when practitioners use the devices. A secure session key is necessary to ensure the security of messages exchanged within the session, while lightweight operation is included because IoMT devices have limited resources in practice. Privacy preservation is required because the information involved pertains to personal health data. Mutual authentication and freshness are also included to ensure mutual verification and secure communication during operation.

Privacy protection is addressed in [51,54]. This highlights that safeguarding users’ sensitive information requires not only cryptographic encryption but also system-level mechanisms that mitigate metadata exposure and behavioral pattern tracking. Similarly, only a limited number of protocols [44,48,49,50,51,53] implement freshness to prevent replay attacks. In addition, only protocols [44,48,51] provide forward and backward secrecy, thereby ensuring the confidentiality of both past and future sessions even if a session key is compromised.

Beyond these classical requirements, emerging threats call for additional considerations. The rapid progress of quantum computing poses fundamental risks to ECC- and RSA-based systems, underlining the need for quantum-resistant cryptographic algorithms in future protocol designs. Moreover, emergency security requirements—such as authentication bypass or rapid identification in urgent scenarios—are largely overlooked in existing works, despite their practical relevance in medical contexts where emergencies are frequent.

These observations underscore the point that while current protocols address fundamental security requirements, future designs must evolve to incorporate advanced properties—including mutual authentication, privacy preservation, quantum resistance, and emergency handling—to achieve comprehensive security in IoMT environments.

Table 3 lists the types and number of operations used in this papers [44,45,46,47,48,49,50,51,53,54], and Table 4 shows hardware specifications and software configurations. The protocols commonly include hash operations and XOR operations and additionally include operations such as public key-based operations, symmetric key operations, and key exchange, as needed. Some protocols also introduce special operations such as fuzzy extractors for biometric information security, modular operation PUFs, and Merkle tree operations.

Table 3. Comparison of computational overhead.

Ref.	${\mathit{C}}_{\mathit{HH}}$	${\mathit{C}}_{\mathit{XOR}}$	${\mathit{C}}_{\mathit{RS}\mathit{AE}}$	${\mathit{C}}_{\mathit{RSAD}}$	${\mathit{C}}_{\mathit{AESE}}$	${\mathit{C}}_{\mathit{AESD}}$	${\mathit{C}}_{\mathit{DH}}$	${\mathit{C}}_{\mathit{FZ}}$	${\mathit{C}}_{\mathit{MOD}}$	${\mathit{C}}_{\mathit{KG}}$	${\mathit{C}}_{\mathit{MT}}$	${\mathit{C}}_{\mathit{PUF}}$	Computation Time
[44]	43	22	1	1	-	-	-	-	-	-	-	-	2.691 $\mathsf{\mu }\mathrm{s}$
[45]	15	13	3	3	-	-	17	-	-	6	-	-	30.631 $\mathsf{\mu }\mathrm{s}$
[46]	8	4	4	4	-	-	10	-	-	-	-	-	6.678 $\mathsf{\mu }\mathrm{s}$
[47]	39	27	-	-	-	-	-	-	-	-	-	-	1.15 $\mathsf{\mu }\mathrm{s}$
[48]	28	13	-	-	2	2	-	3	2	-	-	-	12.657 $\mathsf{\mu }\mathrm{s}$
[49]	57	6	1	1	5	5	-	-	-	1	-	-	32.01 $\mathsf{\mu }\mathrm{s}$
[50]	12	2	-	-	1	1	-	2	-	-	-	-	6.176 $\mathsf{\mu }\mathrm{s}$
[51]	17	3	-	-	4	4	3	-	-	-	-	-	23.989 $\mathsf{\mu }\mathrm{s}$
[53]	35	1	2	2	3	3	4	-	-	1	4	-	21.609 $\mathsf{\mu }\mathrm{s}$
[54]	42	12	1	1	3	3	-	-	-	-	3	2	19.973 $\mathsf{\mu }\mathrm{s}$

$C_{HH}$: cost of hash operation (e.g., SHA-256); $C_{XOR}$: cost of XOR operation (bitwise exclusive-or); $C_{RSAE}$: cost of RSA encryption (asymmetric encryption using public key); $C_{RSAD}$: cost of RSA decryption (asymmetric decryption using private key); $C_{AESE}$: cost of AES encryption (symmetric encryption); $C_{AESD}$: cost of AES decryption (symmetric decryption); $C_{DH}$: cost of Diffie–Hellman key exchange (e.g., ECC scalar multiplication); $C_{FZ}$: cost of fuzzy extractor or matching (e.g., biometric feature processing); $C_{MOD}$: cost of modular exponentiation (e.g., RSA or DH); $C_{KG}$: cost of ECC key generation (key pair generation); $C_{MT}$: cost of Merkle tree computation (e.g., path proof or update); $C_{PUF}$: cost of simulated Physical Unclonable Function (PUF) response generation;

Table 4. Experimental Environment.

Equipment	Specification
CPU	Intel i7-12700 (2.1 GHz)
RAM	DDR-4 16 GB
VGA	NVIDIA GeForce RTX 2080
OS	Microsoft Windows 11 Pro
Compiler	MSVC

Looking at the characteristics of each protocol, Abdussami et al. [44] mostly use only hash and XOR operations to simplify the operation structure and pursues lightweight operation by performing RSA operations only once. Qiu et al. [45] provide high-level asymmetric security with many ECC-based key-generation and exchange operations, but the number of operations is large. Lo et al. [46] also use Diffie–Hellman and RSA operations in a balanced manner and show intermediate complexity. On the other hand, the work by Masud et al. [47] consists of only hash and XOR, so it can be said to be the most lightweight protocol.

Miao et al. [48] combine various elements in authentication by adding biometric information extraction (fuzzy extractor) and modular operations with the basic operations, and Garg et al. [49] strengthen basic security security primarily using hash operations, supplementing them by AES symmetric encryption and digital signature verification. Pradhan et al. [50] proposed a protocol that utilizes AES encryption along with hash functions and XOR operations. Gautam et al. [51] chose a structure that secures basic integrity and confidentiality by using only hash operations, AES, and a small number of DH operations in a relatively simple way.

Su et al. [53] developed a complex structure including ECC key exchange, AES, RSA, and signature verification, aiming to increase defense against various attacks at the same time. Finally, Deebak et al. [54] use PUF and Merkle tree operations in addition to hash operations, XOR, AES, and RSA to additionally ensure security and integrity in special environments such as the IoMT.

Figure 3 graphs the relationship between the computational time of each protocol and the number of security requirements satisfied. The x-axis represents the computational time (in milliseconds) required for each protocol, and the y-axis represents the number of security requirements satisfied. The trendline of the graph was derived by calculating the average slope of all data points. This provides an overall metric for evaluating the tradeoff between security and efficiency.

Figure 3. Comparison of protocols by computational time and satisfaction of security requirements [44,45,46,47,48,49,50,51,53,54].

From the graph, it can be observed that protocols positioned closer to the upper left side of the trendline achieve both higher security and greater computational efficiency. A position above and to the left of the trendline suggests that a protocol satisfies a relatively large number of security requirements while maintaining a lower computational burden, thus demonstrating superior performance. According to the graph, the protocol proposed by Miao et al. is especially notable.

This protocol satisfies a wide range of security requirements, demonstrating a high level of security. In addition, this protocol shows excellent efficiency, with a relatively low computational time compared to other protocols that provide similar security coverage. The balance between security strength and efficiency highlights the practical benefits of this protocol, making it a suitable candidate for environments where both high security and lightweight operation are important. In particular, the combination of lightweight design and meeting comprehensive security requirements shows that this protocol is well-suited for resource-constrained systems in IoMT or next-generation mobile networks.

4. Security Verification

In this section, we evaluate the security of existing proposed protocols and use formal verification tools to check whether each protocol satisfies the main security requirements. Formal verification is a method to comprehensively analyze the validity, safety, and reliability of a protocol through logical reasoning and checking via mathematical models [55]. In this paper, we verify various IoMT authentication protocols using representative formal techniques such as Scyther and SVO Logic. The verification procedure follows the Dolev–Yao adversary model, which assumes that the adversary can eavesdrop on, intercept, and synthesize any message.

For the detailed derivation of the SVO Logic reasoning steps and the Scyther verification process, please refer to the Supplementary Materials.

4.1. SVO Logic

SVO Logic has two rules of inference [56]:

• Modus Ponens: From $\phi$ and $\phi \supset \psi$ infer $\psi$.
• Necessitation: From $⊢\phi$ infer $⊢P\mathrm{believes}\phi$.

‘⊢’ is a meta-lingual symbol that is used in a logical system. ‘$\mathsf{\Gamma }⊢\phi$’ means that $\phi$ can derive from the formula $\mathsf{\Gamma }$(and the axioms given below), and this indicates that $\phi$ can be proven using $\mathsf{\Gamma }$ and axioms. On the other hand, ‘$⊢\phi$’ means that $\phi$ is a theorem that can be derived using only axioms without additional assumptions or formulas, and this indicates that $\phi$ can be proven by itself in the logical system. Evaluation was carried out using SVO Logic notations in Table 5 and the axioms in Table 6, as follows.

Table 5. SVO Logic Notation.

Notation	Meaning
$P\mid \equiv X$	$PbelievesX$
$P◁X$	$PhasreceivedamessagecontainingX.$
$P\mid \sim X$	$PbelievesXwhenPsentit.$
$P|\approx X$	$PhassayingX$
$P◀X$	$OwnsXorrecevieditfromanotherentity.$
$P\Rightarrow X$	$PhasacontrolonX$
$\#\left(X\right)$	$Xisnewlygeneratedandhasneverbeentransmittedbefore$
$P\stackrel{K}{⟷}Q$	$PandQcommunicatesecurelythroughthecommonkeyK$
$\stackrel{P{K}_P}{⟶}P$	$P{K}_{P}isP’spublickey,andonlyPcandecryptmessagewith{P}^{\prime }sprivatekey$
${\left\{X\right\}}_K$	$XencryptedbyK$
${\lfloor X\rfloor }_K$	$XsignedwithkeyK$
${⟨X⟩}_{\ast P}$	$ThereceivedmessageXisunrecognizedbyP$

Table 6. SVO Logic Axioms.

Axioms	Formula
Believing Axioms (BA)	1. $P\mid \equiv \phi \wedge P\mid \equiv (\phi \supset \psi )\to P\mid \equiv \psi$ 2. $P\mid \equiv \phi \supset P\mid \equiv (P\mid \equiv \phi )$
Source Association Axiom (SAA)	1. $(P\stackrel{K}{⟷}Q\wedge P◁{\left\{X\right\}}_K)\to \left(Q\right|\approx X\wedge Q◀X)$
Receiving Axioms (RA)	1. $P◁(X_1,\dots ,X_n)\supset P◁X_i$ 2. $(P◁{\left\{X\right\}}_K\wedge P◀\stackrel{\sim }{K})\supset P◁X$
Possession Axioms (PA)	1. $P◁X\to P◀X$ 2. $P◀(X_1,\dots ,X_n)\to P◀X_i$ 3. $(P◀X_1\wedge \dots \wedge P◀X_n)\to P◀F(X_i,\dots ,X_n)$
Comprehension Axioms (CA)	1. $P\mid \equiv (P◀F(X\left)\right)\supset P\mid \equiv F\left(X\right)$
Saying Axioms (SA)	1. $P\mid \sim (X_1,\dots ,X_n)\to P\mid \sim X_i\wedge P◀X_i$ 2. $P\mid \sim (X_1,\dots ,X_n)\to \left(P\right|\approx X_1,\dots ,X_n)\wedge P\mid \sim X_i$
Freshness Axioms (FA)	1. $\#\left(X_i\right)\to \#\left((X_1,\dots ,X_n)\right)$ 2. $\#\left((X_1,\dots ,X_n)\right)\to \#\left(F(X_1,\dots ,X_n)\right)$
Jurisdiction Axiom (JR)	1. $(P\Rightarrow \phi \wedge P\mid \sim \phi )\to \phi$
Nonce-Verification Axioms (NV)	1. $(\#(X)\wedge P\mid \sim X)\to P|\approx X$
Diffie-Hellman Key Exchange Axioms (DH)	1. $(P\mid \equiv Q\mid \sim \stackrel{P{K}_Q}{⟶}Q\wedge P\mid \equiv \stackrel{P{K}_P}{⟶}P)\to P\mid \equiv S$

In this section, we present the result of Formal verification using SVO Logic for the 10 authentication protocols presented in this paper. In [44,48,49], the designed protocols clearly prove security through formal verification based on SVO Logic. The logical basis for secure session key exchange in each protocol is clearly presented. This is achieved through a structured reasoning process based on SVO Logic.

First, Abdussami et al. [44] supports mutual authentication and sharing of the secure session key with systematically derived steps such as (DA.4), (DA.5), (DA.9), (DA.13), (DA.17), and (DA.18), as given in the Appendix A of this study. These derivation steps validate that the session key is securely established between both entities. Specifically, in [48], steps (DE.11), (DE.16), and (DE.17), as given in the Appendix E of this study confirm the correctness of the key-exchange process. In particular, although the MSN’s indirect belief is not explicitly shown in the derivation step, it is confirmed that the authentication is stated as an assumption in (AE.14) of the Appendix E. This indicates that the MSN trusted the session key during the message-exchange process after the key had been shared.

Finally, in the case of [49], mutual authentication and secure session key exchange are clearly demonstrated. These properties are verified through a series of derivation steps, including (DF.5), (DF.10), (DF.15), (DF.20), (DF.21), and (DF.25), as given in the Appendix F of this study. As a result, the protocol is shown to be robust against key forgery and man-in-the-middle attacks.

In addition, each protocol satisfies forward/backward secrecy by deriving the session key through a combination of a hash function and a randomly generated number for each session. As illustrated in the session key-agreement process in [44], (DA.4), (DA.8), (DA.13), and (DA.17), as given in the Appendix A, from the derivation process, it can be inferred that each session key is generated independently using fresh randomness. This ensures that session keys are cryptographically isolated, preserving both forward and backward secrecy. In the [48], it is also derived in (DE.11), as given in the Appendix E of this study and (DE.16) that the session key is generated by a hash function with a new random number, which ensures key independence between sessions. In [49], the derivation steps (DF.5), (DF.10), (DF.15), and (DF.20), as given in the Appendix F of this study, confirm that the session key is freshly generated for each session. As the new key is not logically linked to any previous session, the protocol satisfies both forward and backward secrecy. In [50], the key agreement steps (DG.5) and (DG.12), as given in the Appendix G of this study, employ the session timestamp to generate a unique key value for each session. Consequently, the newly generated key value differs from that of the previous session, ensuring that the proposed protocol satisfies both PFS and PBS. In addition, by incorporating a mutual key verification process based on the session key in subsequent steps, the protocol is also verified to achieve the mutual authentication.

Whereas the protocols proposed in [45,51,53,54] appear to verify user identity through an authentication process on the surface, they lack a proper mutual authentication structure. This is revealed in the fact that session key verification was not performed, as the mutual trust in key sharing, which is one of the main security goals defined in SVO Logic, was not derived.

The SVO Logic verification of the protocols set goals for sharing and verifying session keys such as (GB.2), (GB.4), (GH.4), (GH.9), (GI.2), (GI.4), (GJ.3), and (GJ.6), as given in the Appendix B, Appendix H, Appendix I, and Appendix J of this study, but failed to derive the goals in the message-derivation phase.

In addition, the protocols proposed in [45,46,47,54] omit verification of the random numbers or timestamps included in messages, resulting in structural flaws that fail to prove message freshness. Consequently, these protocols are vulnerable to replay attacks. As a result of the formal verification, freshness-related assumptions were not explicitly adopted during the assumption phase in these protocols. Instead, they were expressed as hypotheses in forms such as (HB.1), (HB.2), (HB.3), (HC.1), (HC.2), (HD.1), (HD.2), (HD.3), and (HJ.1), as given in the Appendix B, Appendix C, Appendix D, and Appendix J of this study, indicating a lack of clear justification or evidence that these elements represent truly fresh values.

In SVO Logic, a hypothesis is treated as an assumption that lacks formal proof. As such, it cannot serve as a valid basis for deriving goals related to freshness, such as replay attack resistance or session key reliability. In other words, if freshness—one of the core security requirements—is not formally established, the protocol may become vulnerable to attacks involving the reuse of past messages, leading to threats such as session key exposure and authentication bypass.

In conclusion, the protocols proposed in [45,46,47,54] lack a systematic mechanism to formally prove message freshness. This limitation is evident in the SVO Logic analysis, where freshness-related assumptions are treated merely as unproven hypotheses. As a result, these protocols fail to achieve freshness-based security goals through formal reasoning, making them vulnerable to replay and time-based attacks and ultimately undermining their reliability as secure authentication protocols.

For transparency and reproducibility, we have included in the Appendix A, Appendix B, Appendix C, Appendix D, Appendix E, Appendix F, Appendix G, Appendix H, Appendix I and Appendix J the security verification we performed for all 10 protocols using SVO Logic: annotation, comprehension, interpretation, assumption, goal, and derivation.

4.2. Scyther

The Scyther tool is used to automatically verify the security properties of the protocol. For this purpose, the protocol is transformed into the Security Protocol Description Language (SPDL) and the participants (roles) are defined along with their corresponding behaviors, such as nonce generation, session key computation, and message transmission. Furthermore, claim() events are inserted within each role to determine whether the specified security requirements have been satisfied. Verification is carried out by modeling the protocol in SPDL and validating the achievement of the intended security goals through queries expressed in the form of claim() statements [57].

The Secret attribute is used to verify whether the confidentiality of a target element is preserved. When the Secret attribute is satisfied, the element is not exposed to the attacker even if it is transmitted over a public channel. The Secret attribute is used to check whether the confidentiality of specific data items is maintained within a protocol. The SKR attribute is similar to the Secret attribute, but it is specifically applied when verifying the confidentiality of a session key. The Alive attribute denotes the liveness of a role. It indicates that all agents participating in the protocol actively perform their roles until the end of communication. The Weakagree attribute ensures that when two agents believe that they have executed the protocol, they mutually agree on that fact. In other words, the communication counterpart must be the legitimate entity and not an attacker. The Nisynch attribute denotes non-injective synchronization. Non-injective synchronization verifies that everything occurs in execution exactly as intended by the protocol. The Niagree attribute refers to non-injective agreement on messages. It ensures that the messages exchanged within the protocol match exactly in their content.

The protocol [44] first allows the IoMT sensor and the medical server to authenticate each other. Then, it enables mutual authentication between the doctor and the medical server. We modeled the sensor–server and doctor–server communications as two separate files. In the sensor–server analysis, Alive and Weakagree claims for both entities returned “OK.” However, the Nisynch and Niagree claims failed. This indicates that the protocol does not guarantee correct message order or exact correspondence between transmitted and received messages. This result shows that the sensor–server communication requires stronger authentication mechanisms. In contrast, the doctor–server analysis showed that all Alive claims for both entities returned “OK.” These findings confirm the security of communication between the doctor and the medical server.

To evaluate the security of [45], we verified the Alive, Weakagree, Nisynch, and Niagree attributes of the participating entities. Participating entities include patients and doctors. Additionally, we analyzed whether the CID exchanged between them maintained confidentiality. Since IPFS functions solely as a medium for storage and transmission and does not perform any cryptographic operations, it was not defined as a separate role in the model. The lack of such measures creates a vulnerability that allows messages modified by a malicious patient to go undetected.

The analysis confirmed the confidentiality of the CID, as well as the Alive, Weakagree, Nisynch, and Niagree attributes for doctors and the Alive and Weakagree attributes for patients. However, the patient’s Nisynch and Niagree attributes failed to meet the security requirements, indicating vulnerabilities in synchronization and agreement.

They modeled the protocol [46] by combining the registration and authentication phases into a single file. As certain steps rely on public key encryption, they were represented using the $pk$ function. The protocol does not establish a session key, so we did not test the SKR claim and instead examined only the confidentiality of the medical data $SData$. The analysis shows that Alive, Nisynch, Niagree, and Weakagree claims for the doctor, the Service Provider (SP), and the gateway all return “OK”. This outcome confirms their activities and mutual authentication.

Masud et al. [47] proposed a protocol in which each agent generates a PUF through the const declaration. The Scyther model includes the registration phase without omission. It also represents the registration and authentication processes within a single file. The gateway, sensor node, and doctor show “OK” for Alive, Nisynch, Niagree, and Weakagree claims. These results confirm liveness and mutual authentication among the entities. The SKR claim for the session keys also returns “OK,” verifying that the confidentiality of the session key remains intact. Therefore, the protocol meets essential security requirements.

In the modeling of the protocol [48], the registration phase operates over a secure channel. It is therefore simplified to highlight the essential information exchange. The Diffie–Hellman key exchange used in this process is modeled through a helper protocol. Claims such as Alive, Nisynch, Niagree, and Weakagree for both the gateway node and the user are all marked “OK”. This confirms liveness and mutual authentication between the entities. The SKR claim between the medical sensor node and the user is also marked “OK”. This result verifies that the confidentiality of the session key is preserved. No attacks were detected during the communication. These outcomes demonstrate that the protocol ensures secure transmission.

In the Scyther modeling of the protocol [49], we included only the user registration, login, and authentication with key-agreement phases. The preliminary phase defines a Trusted Authority (TA) responsible for distributing the required elements. For the user, Alive, Nisynch, Niagree, and Weakagree claims all return “OK.” These results confirm liveness and successful authentication. The SKR claim between the user and the cloud server also returns “OK,” ensuring user authentication and session key confidentiality from the server’s perspective. In contrast, the cloud server shows “Fail” for Alive, Nisynch, Niagree, and Weakagree claims. This result indicates that the protocol does not authenticate the server. However, because Scyther cannot accurately verify timestamps, cross-validation must be conducted with another tool, namely SVO as employed in this paper.

During the modeling of the [50], ambiguity arose in the computation involving the fog node’s private key $S{K}_F$. This issue was addressed by treating $S{K}_F$ as equivalent to a nonce $r{n}_i$. In addition, we corrected several typing errors identified in the original text and reflected them in the Scyther code to ensure analytical accuracy. The verified properties included Alive, Weak Agreement, Nisynch, and Niagree for both the User (U) and the Fog Node (FN), along with the secrecy of the session key exchanged between them. The analysis revealed that the user’s Nisynch and Niagree properties, as well as the session key secrecy, failed to satisfy the security criteria. The fog node also failed to meet the Nisynch and Niagree properties, indicating vulnerabilities in synchronization and agreement assurance. This result reveals that the protocol does not provide server authentication. Given that Scyther cannot ensure accurate timestamp verification, cross-checking is required with an alternative method, in this case, the SVO, as utilized in this paper.

The proposed protocol [51] consists of message exchanges among the user, the gateway, and the sensor node. During the user-registration phase, we analyzed the use of the Diffie–Hellman key-exchange method and incorporated it into the modeling process by adding a supplementary protocol. We conducted the security verification by examining the Alive, Weakagree, Nisynch, and Niagree properties for each entity. We also verified the confidentiality of the session key exchanged among the entities. The analysis showed that all verification claims returned “OK”, which confirmed both the liveness of each entity and the satisfaction of mutual authentication. Furthermore, the results demonstrated the confidentiality of the session key, thereby proving that the proposed protocol ensures reliable security.

We modeled the registration phase of the protocol [53] by assuming it had already been completed. In this setting, the gateway transmitted all required elements together. The verification results indicate that the user satisfied all Alive, Nisynch, Niagree, and Weakagree claims. We also confirmed the confidentiality of both the session key and the gateway’s master key x. However, the gateway did not satisfy the AliveAlive and Weakagree claims, and the sensor device did not satisfy any of the Alive, Nisynch, Niagree, and Weakagree claims. These results indicate that the authentication of the gateway and the sensor device is ineffective during communication. The proposed protocol often relies on XOR functions. However, because Scyther is unable to process XOR operations, manual modeling becomes necessary; this can introduce unintended false positives. Thus, protocols containing XOR must be cross-validated with alternative verification tools.

The protocol [54] specified a single file that sequentially includes the registration and authentication steps. Analysis using Scyther revealed that the Alive, Nisynch, Niagree, and Weakagree claims for the Mobile Equipment (ME), Access Gateway (AG), and Medical Server (MS) all returned “OK.” This confirms that each participant’s activities were normal and that mutual authentication was successfully achieved.

5. Discussion

The analysis presented in Figure 2 shows that there is a trade-off relationship between computational cost efficiency and robust security among the proposed protocols. In general, protocols that satisfy many security requirements have higher computational costs. Other protocols with lower computational overhead have lower security. This relationship is very important in real environments, especially in resource-constrained environments and in environments where security and responsiveness are equally critical.

Table 7 briefly summarizes the formal verification results. This table indicates whether the authors of each paper conducted the verification and the results of our verification via SVO-Logic and Scyther. We observed that most protocols satisfied fundamental security requirements such as authentication, confidentiality, and integrity. However, many protocols are found to be inadequate in meeting the main security requirements, including key agreement, the consistency of communication objectives, and confidentiality assurance. Despite these limitations, the protocols presented in [44,48] demonstrated robustness in both verification approaches, indicating a comparatively higher level of security than the other protocols.

Table 7. Security Verification Result.

Ref.	Verification by the Authors’ Own	SVO	Scyther	Scyther Properties
				Niagree	Nisynch	Weakagree	Secret	SKR	Alive
[44]	$O\left(Scyther\right)$	×	×	✓	✓	✓	✓	✓	✓
[45]	$O\left(AVISPA\right)$	×	×	×	×	✓	✓	✓	✓
[46]	−	×	O	✓	✓	✓	×	✓	✓
[47]	−	×	O	✓	✓	✓	✓	✓	✓
[48]	$O(BAN-Logic)$	O	O	✓	✓	✓	✓	✓	✓
[49]	$O\left(AVISPA\right)$	O	×	×	×	×	✓	✓	×
[50]	$O(ProVerif,BAN-Logic)$	O	×	×	×	✓	×	✓	✓
[51]	−	×	O	✓	✓	✓	✓	✓	✓
[53]	$O\left(ProVerif\right)$	×	×	×	×	×	✓	✓	×
[54]	−	×	O	×	×	×	×	×	×

O: Passed, ×: Unpassed/Unsatisfied, ✓: Satisfied.

Among the protocols reviewed in this paper, the scheme proposed by Miao et al. [48] stands out. This protocol shows a relaxation of the trade-off relationship between security and efficiency. The proposed scheme satisfies a wide range of security requirements. The proposed method maintains relatively low computational time compared to other protocols that achieve similar security levels. This shows that the protocol proposed by Miao et al. [48]. The protocol is suitable for environments such as IoMT systems that require both strong security and a lightweight protocol.

Miao et al. [48]’s protocol was formally verified using SVO Logic and Scyther. The analysis confirmed logical derivations of mutual authentication, session freshness, key agreement, and key confirmation. These results indicate that the protocol satisfies critical security properties while maintaining computational efficiency.

The verification results further emphasize the practical value of the protocol. It not only demonstrates mutual authentication, key agreement, and efficiency, but also shows potential applicability in real-world deployments. In particular, its strengths suggest that it may be well-suited for resource-constrained environments or scenarios requiring strong security guarantees. Nonetheless, moving from theoretical validation to practical adoption requires careful consideration of its limitations.

6. Conclusions

IoT technology has led to significant transformations in the medical sector. In particular, the growth of the elderly population and the increasing prevalence of chronic diseases have continuously heightened the demand for personalized medical services. To address these emerging challenges, the need for intelligent medical systems capable of supporting real-time patient monitoring and data-driven medical decision-making is becoming increasingly critical.

The IoMT is revolutionizing the provision of healthcare services across diverse environments by interconnecting MDs, wearable devices, and point-of-care diagnostic equipment. Furthermore, IoMT technologies are being integrated into hospital-management systems to facilitate the real-time monitoring of medical assets and facilities and to enable seamless sharing of health data between patients and healthcare providers. This integration enhances the delivery of various medical services, including preventive care, management of chronic disease, and emergency response.

Within IoMT environments, data transmission serves as a fundamental determinant of overall system efficiency and reliability. Health data collected by sensors and medical devices must meet stringent requirements concerning security, reliability, latency, and energy efficiency. Given the sensitive nature of medical information, any compromise in data integrity or transmission reliability could pose direct threats to patient safety. Consequently, the development of secure and efficient data-transmission methods is of paramount importance.

In practice, the selection of an authentication protocol must balance the importance of security requirements with the available computational resources. Lightweight schemes may be preferable for resource-constrained IoMT nodes, whereas critical systems require protocols with stronger security guarantees despite higher costs.

In this context, this paper comprehensively analyzes recently proposed authentication protocols in terms of security requirements, computational costs, and formal verification results to explore protocols suitable for the IoMT environment. The results highlighted the protocol proposed by Miao et al. [48], confirming the importance of balancing environmental characteristics and security in future IoMT protocol development.

This evaluation has several limitations. First, it assumed that all security requirements are equivalent and did not consider that their importance may vary depending on the application scenario. Second, the computational time was collected under general conditions, and actual performance may differ across hardware platforms and operational environments.

In future research, we plan to design an authentication protocol that optimizes the trade-off between security and computational efficiency by systematically categorizing diverse use cases and prioritizing security requirements according to their relative importance in each application environment.