Understanding IoMT Cybersecurity: Protecting Connected Healthcare IoT Devices

Hospitals now depend on connected medical devices to monitor patients and support treatment. These devices share clinical information through hospital networks and cloud platforms. They also connect with mobile applications and electronic health records. Still, if a security breach happens, it can change how these devices work and endanger safety.

The concern is growing as healthcare cyberattacks continue. In the first half of 2026, 397 large healthcare data breaches were reported to HHS OCR. These incidents affected 33.77 million individuals, with more than two breaches reported each day.

So what can healthcare organizations do to improve IoMT cybersecurity without interrupting treatment? This guide looks at the major threats and practical security measures that can help protect connected medical devices.

What Is the Internet of Medical Things?

The Internet of Medical Things (IoMT) refers to connected medical devices and supporting technologies that gather and transmit health information. Some devices monitor patients, and many help doctors diagnose conditions or deliver treatment. These systems can also receive instructions or process clinical data.

What makes IoMT different from other connected technologies is its medical purpose. A device does not need direct internet access to be part of IoMT. It may communicate through a hospital's internal network or connect to another medical system.

Common examples of IoMT devices include:

-> Patient monitoring: 

• ECG machines
• Pulse oximeters
• Glucose monitors
• Wearable medical sensors.

-> Treatment equipment: 

• Infusion pumps
• Ventilators
• Dialysis machines
• Connected surgical systems

-> Diagnostic equipment: 

• MRI scanners
• CT scanners
• Ultrasound machines
• X-ray systems
• Laboratory analysers

-> Implantable devices: 

• Connected pacemakers
• Other cardiac devices.

-> Remote care equipment: 

• Home medical devices
• Remote patient monitoring systems

-> Supporting systems: 

• Medical device gateways
• Connected smart beds with clinical functions
• Central device management platforms

Many of these devices communicate with electronic health records (EHRs) or clinical applications. Some also exchange information through mobile apps and cloud services. Manufacturers may use dedicated portals to manage supported equipment.

These connections allow healthcare professionals to access device information without always being physically present beside the patient.

What Is IoMT Cybersecurity?

IoMT cybersecurity refers to the security technologies, processes, monitoring practices, and risk management methods used to protect connected medical devices. It helps prevent unauthorized access, data theft, device manipulation, and service disruptions that could affect patient care. Protection covers both medical equipment and the systems supporting its operation.

This includes device firmware, embedded software, network communications, gateways, applications, APIs, cloud platforms, vendor connections, and software dependencies.

Unlike traditional IT security, which focuses on 3 main principles, IoMT cybersecurity must address four:

• Confidentiality: Prevent unauthorised access to medical information
• Integrity: Keep clinical data and device instructions accurate
• Availability: Maintain access to essential medical systems
• Patient safety: Prevent cyber incidents from causing patient harm

Why IoMT Cybersecurity Matters for Healthcare

A cyberattack on hospital technology can affect how quickly patients receive care and whether medical equipment works as intended. For healthcare organisations, IoMT cybersecurity matters because the consequences can extend beyond financial losses or exposed records.

Patient Safety

Some medical devices continuously measure a patient's condition. Others control equipment used during treatment. If an attacker changes device settings or interferes with measurements, healthcare professionals may receive incorrect information or the equipment may behave unexpectedly.

Clinical Availability

A hospital can lose access to essential medical services even when the devices themselves have not been attacked.

Ransomware affecting a hospital network may prevent imaging systems from sending results to clinicians. If authentication services or medical device gateways stop working, staff may struggle to access the applications they need.

Such disruptions can delay examinations and treatment decisions. Hospitals must therefore consider how long clinical services can continue when supporting technology becomes unavailable.

Data Integrity and Patient Information

Stealing patient information and changing clinical data can lead to different consequences.

A data breach may expose electronic protected health information (ePHI). Altered medical readings or corrupted patient records can affect the decisions clinicians make during treatment.

Hospital Network Security

An inadequately protected medical device may give attackers access to other hospital systems.

Once inside a network, attackers may attempt to steal credentials or identify additional vulnerable systems. They could also establish persistent access and move between connected networks.

This makes cyber risks relevant to the entire hospital. Biomedical engineering teams and IT security departments need to coordinate their responsibilities rather than managing device protection separately.

Why Are IoMT Devices Difficult to Secure?

Medical devices have different security requirements from regular IT equipment. Hospitals often use equipment that cannot support newer security software or receive updates without manufacturer involvement. The following challenges make IoMT cybersecurity harder to manage.

1. Long Device Lifespans and Legacy Software

Hospitals may use the same medical equipment for many years because it remains clinically functional. However, the operating system may stop receiving security updates long before the equipment needs replacing.

For hospitals, replacing unsupported systems may require new equipment or changes to existing clinical workflows. This makes replacement planning necessary alongside regular security maintenance.

2. Limited Endpoint Security Support

Many medical devices cannot accommodate conventional endpoint detection and response (EDR) software. Some have limited processing capacity, while others restrict the installation of additional applications.

Security teams must therefore consider protection methods that work without installing software directly on the equipment.

3. Restrictions on Software Updates

Medical device updates may require additional checks before installation. Unlike ordinary computers, hospitals cannot assume that every available update is suitable for their equipment.

Common requirements include:

• Manufacturer compatibility confirmation
• Testing to identify potential performance issues
• Approval from clinical and biomedical teams
• Scheduled maintenance and possible device restarts

The FDA recommends validating cybersecurity changes to ensure they address vulnerabilities without introducing additional risks.

4. Different Manufacturers and Device Configurations

Hospitals may operate equipment from numerous manufacturers. Each device can have different software requirements and maintenance procedures.

Some products receive updates remotely. Others require manual servicing by authorised technicians. Security teams must account for these differences when maintaining equipment across departments.

5. Dependence on Device Manufacturers

Hospitals do not always have permission or the technical ability to modify medical device software independently. They may need manufacturers to provide security patches or explain newly discovered vulnerabilities. Remote maintenance and configuration changes can also depend on vendor support.

If support ends, the hospital may have fewer options for maintaining the equipment securely.

6. Incomplete Device Inventory

Standard IT management tools may not identify every connected medical device. Some use specialised communication methods or operate through gateways that conceal individual devices from conventional discovery systems.

Makes it harder to track software versions, support status, and maintenance requirements. Hospitals need accurate asset records to determine which equipment needs attention.

Where Does the IoMT Attack Surface Exist?

The IoMT attack surface includes every point where someone could gain unauthorised access to a medical device or its connected systems. A weakness may exist inside the equipment itself or in the technology it communicates with.

For effective Internet of Medical Things cybersecurity, healthcare organisations need to examine five areas.

Device and Firmware Layer

Medical devices rely on firmware and embedded software to perform their functions. Security weaknesses can be difficult to detect because they exist within the device's operating components.

Common weaknesses include:

• Insecure firmware: Outdated components or software with known vulnerabilities
• Unverified firmware: Missing digital signature checks that could allow modified firmware to be installed
• Weak authentication: Hardcoded passwords or credentials that are easy to obtain
• Insecure storage: Sensitive information stored without sufficient protection
• Exposed interfaces: Debug ports that could permit unauthorised access during physical contact
• Insecure boot: Missing checks that would otherwise help prevent unauthorised code from loading

Someone exploiting these weaknesses may gain persistent access or change how the device operates. Physical access can also allow tampering if hardware interfaces are poorly protected.

Communication Layer

Medical equipment exchanges information through WiFi, Bluetooth, Bluetooth Low Energy (BLE), Ethernet, and cellular networks. Some products also use proprietary radio frequency connections.

The connections themselves become vulnerable when communication protocols lack appropriate security controls. For example, weak encryption or improper Transport Layer Security (TLS) validation may allow attackers to intercept information. Poor authentication can make it easier to impersonate a trusted device or gateway.

Hospital Network Layer

Hospital networks often connect medical equipment with other clinical technology. Problems arise when devices can communicate with systems they do not need to access.

The main exposure points include:

• Flat networks with limited separation between devices
• Incorrect VLAN configurations or overly permissive network rules
• Unnecessary open ports and exposed services
• Unsecured remote connections
• Shared administrative credentials

A vulnerable device on a poorly separated network allows an attacker to reach other connected assets. Proper network boundaries help limit how far an intrusion can spread.

For example, an attacker who compromises a networked medical workstation could attempt to reach device management servers or other clinical systems. The attack becomes easier when internal connections are broadly permitted.

Application, API, and Cloud Layer

Medical devices often connect to management dashboards, mobile applications and cloud services. These platforms introduce access points outside the physical equipment.

Weak identity verification or incorrect access permissions can allow someone to take control of an account. Insecure APIs can expose information or permit actions that the user should not be authorised to perform.

Specific concerns include:

• Applications that allow access to patient information without properly checking user permissions.
• APIs that expose device records or management functions to unauthorised requests.
• Cloud storage with incorrect access settings.
• Poorly protected authentication tokens that could be used to access connected services.

Cloud storage and EHR integrations need particular attention because they handle sensitive clinical information.

For example, an API that fails to verify which device records a user is authorised to access could expose information belonging to other patients or healthcare departments.

Where device management functions are available through these platforms, compromised accounts could also permit unauthorised configuration changes.

Vendor and Software Supply Chain Layer

Medical device security also depends on software and services provided by external organisations.

Potential weaknesses can originate from:

• Open source components and embedded software libraries
• Commercial software supplied by third parties
• Firmware developed by external suppliers
• Cloud infrastructure and service providers
• Vendor support accounts and remote maintenance tools

A vulnerable software dependency may affect several device models that use the same component. Similarly, compromised vendor credentials could expose equipment maintained through remote support connections.

How Should Healthcare Organizations Prioritize IoMT Vulnerabilities?

A high vulnerability score does not always mean a medical device needs immediate attention. The Common Vulnerability Scoring System (CVSS) measures the severity of software weaknesses, but it does not account for the device's clinical function or its exposure to attackers.

When you are deciding which vulnerabilities to address first, your security team should examine:

• Evidence of exploitation: Check whether attackers are already using the vulnerability. Look for reports of active exploitation and entries in CISA's Known Exploited Vulnerabilities catalog
• Device accessibility: Find out who can reach the equipment. A device accessible through an insecure internet connection presents different risks from one restricted to a controlled internal network. Also check whether exploitation requires physical access
• Role in patient care: Consider what the equipment does. A vulnerability affecting a life-supporting device needs particular attention because of the potential consequences for patients
• Consequences of compromise: Determine what would happen if someone altered device readings or interrupted its operation. Consider whether clinicians could continue treatment safely using alternative equipment
• Existing protection: Review whether access restrictions, network segmentation or application allowlisting already reduce the opportunity for exploitation.

Claroty's 2025 research examined over 2.25 million IoMT devices across 351 healthcare organisations. The report identified exploited vulnerabilities in connected equipment and found that 89% of the organisations had devices combining known exploited vulnerabilities, ransomware associations and insecure internet connections.

How to Secure IoMT Devices in Healthcare

1. Discover Every Connected Medical Asset

Begin with a complete inventory of medical devices across your healthcare network. Include equipment managed by IT teams and biomedical departments. Look for unknown or unregistered devices as well.

Record the following details for each asset:

Device information: 

• Manufacturer
• Model, type
• Location

Software details: 

• Operating system
• Firmware version

Clinical details: 

• Purpose
• Department
• Responsible owner

Connectivity: 

• Network interfaces
• Dependencies
• Normal communication patterns

Support status: 

• Vendor support availability
• End of support date

Security details: 

• Known vulnerabilities
• Existing protections

Use passive network monitoring and compare the results with procurement and maintenance records. Update the inventory whenever equipment changes.

2. Classify Devices by Clinical Criticality

Group your equipment according to the consequences of a failure or security incident.

Use these categories:

• Administrative IoT: Devices supporting routine hospital operations without a direct clinical function
• Diagnostic devices: Equipment used to examine patients and identify medical conditions
• Monitoring devices: Systems that track patient health and provide clinical readings
• Treatment devices: Equipment involved in delivering medication or medical procedures
• Life-supporting devices: Equipment essential to maintaining critical bodily functions

Work with clinical and biomedical teams to assign each device a criticality level. Use these classifications when setting maintenance priorities and deciding how to respond to security incidents.

3. Establish Expected Device Behavior

Determine how each medical device normally communicates before applying network restrictions. Consult the manufacturer and clinical teams to confirm which connections are necessary.

Document the following:

• Approved destinations: Servers and systems the device needs to access
• Protocols and ports: Communication methods required for normal operation
• Internet access: Whether the device requires an external connection
• EHR integrations: Expected communication with patient record systems
• Internal traffic: Required connections between devices and hospital systems
• Cloud dependencies: External platforms needed for device functions
• Vendor access: Authorised connections used for maintenance and technical support

Compare observed network traffic with these requirements. Investigate unexplained connections before approving them.

4. Segment the Clinical Network

Group medical devices according to their clinical function and security requirements. Use the communication baseline established in the previous step to define network access rules.

• Separate devices based on sensitivity and trust level
• Use segmentation or microsegmentation to restrict communication between unrelated systems
• Configure firewalls to allow only approved traffic between network segments
• Test access rules with clinical teams before enforcing them to avoid blocking necessary communication

Review the rules whenever device connections or clinical requirements change.

5. Apply Least Privilege

Control who can access medical devices and what actions they can perform.

• Assign user permissions based on clinical responsibilities.
• Give service accounts only the permissions needed for their tasks.
• Restrict applications from accessing unnecessary device functions or sensitive data.
• Reserve administrative settings and management interfaces for authorised personnel.
• Remove unused accounts and permissions when staff roles change.

6. Strengthen Authentication and Access

Secure medical device accounts to prevent unauthorised access.

• Replace factory default passwords wherever the device supports it.
• Set unique credentials for each device and administrator.
• Use multifactor authentication for remote and privileged access where technically supported.
• Avoid shared vendor login credentials so individual activity remains traceable.
• Monitor administrative logins and changes to device settings.
• Investigate unusual login attempts and revoke compromised credentials.

7. Protect Data and Communications

Encrypt medical information during transmission and storage wherever the device supports it. Secure connections between medical equipment and the gateways, applications, cloud services, or EHR systems it uses. 

For older devices that cannot support modern encryption, consider compensating controls such as secure gateways or encrypted network tunnels. Confirm compatibility with the manufacturer before making changes.

8. Patch According to Clinical Risk

Before installing a patch, check whether the reported vulnerability affects any equipment in use. Confirm its exposure and consult the manufacturer's instructions.

Once the update is approved:

1. Assess whether installation could affect clinical functions
2. Test the update if required
3. Arrange a suitable maintenance window with the clinical team
4. Install the patch and check that the device works as expected
5. Record the update and any remaining security concerns

If a patch cannot be installed safely, document the reason and apply temporary safeguards until the issue can be resolved.

9. Apply Compensating Controls When Patching Is Not Possible

If a medical device cannot receive security updates, check which functions can be restricted without affecting its operation. Disable unused services and remove unnecessary internet access.

For devices that must remain connected, tighten network isolation and firewall permissions. Use behavioural monitoring to detect unusual activity. Secure gateways and stricter vendor access can provide further protection where needed.

Document the remaining risks and review these measures regularly. If the manufacturer no longer supports the device, prepare a replacement plan rather than relying on temporary controls indefinitely.

10. Monitor Devices Without Creating New Clinical Risk

Aggressive vulnerability scans can interfere with sensitive or older medical equipment. Check with the manufacturer before running active scans and use passive network monitoring where appropriate.

Monitor device traffic and security logs for unusual activity. Configure alerts to account for each device's clinical function so routine operations do not trigger unnecessary warnings.

Where supported, send relevant device logs and network telemetry to your Security Information and Event Management (SIEM) platform. This allows the Security Operations Center (SOC) to investigate suspicious activity alongside other hospital security events.

11. Secure Third-Party Remote Access

Vendor access should remain closed unless an approved maintenance task requires it. Give each technician an individual account and require MFA wherever supported.

Before granting access, confirm the devices the technician needs and set an expiry time for the session. Record remote activity so your security team can review what was accessed and changed.

Once servicing is complete, close the connection and revoke temporary permissions. Disable dormant vendor accounts to prevent unnecessary access from remaining available.

12. Integrate IoMT Into Incident Response

Include connected medical devices in hospital incident response plans and conduct regular exercises with clinical staff.

Assign clear responsibilities:

• SOC teams investigate suspicious activity and assess the incident.
• Network teams identify affected connections and containment options.
• Biomedical engineers assess device functionality and technical limitations.
• Clinicians determine whether treatment can continue safely.
• Manufacturers provide device-specific technical guidance.
• Incident leaders coordinate decisions and communication.

If a device shows suspicious activity during treatment, do not disconnect or restart it without assessing the clinical consequences. Work with the care team to determine whether the patient needs alternative equipment before taking containment action.

How to Secure Legacy Medical Devices That Cannot Be Patched

Healthcare organisations generally have 3 options.

1. Patch

Patching is the preferred option when the manufacturer still supports the device and provides a suitable security update.

Before proceeding, confirm that the update is compatible with the equipment and does not introduce unacceptable clinical risks. If both conditions are satisfied, the device can remain in service after successful installation and verification.

2. Isolate

Some medical devices remain essential even though their software cannot be updated. In such cases, continued use requires additional protection.

Depending on the equipment, hospitals can restrict network communication, remove unnecessary internet connections, and disable unused services. Secure gateways and tighter vendor access controls can further limit exposure.

Isolation is not a permanent solution to every vulnerability. Security teams should reassess the remaining risk whenever new weaknesses are discovered, or the device's operating conditions change.

3. Replace

Replacement becomes necessary when continued use presents risks that existing safeguards cannot adequately control.

Pay particular attention to equipment that:

• No longer receives security support from its manufacturer.
• Contains serious vulnerabilities without effective mitigation options.
• Cannot support required authentication or encryption.
• Depends on unsupported operating systems or software.
• Remains exposed despite available protective measures.
• Presents an unacceptable risk to patient safety.

IoMT Cybersecurity Standards and Frameworks to Know

Different standards address different aspects of iomt cybersecurity. Some help manufacturers manage security risks during device development. Others guide hospitals in protecting connected equipment and the networks supporting it.

How Medysec Helps Medical Device Manufacturers Strengthen IoMT Cybersecurity

Medical device manufacturers need to identify security weaknesses before their products reach the market. They also need evidence of testing and risk management to support regulatory submissions.

Medysec helps manufacturers of connected medical devices, Software as a Medical Device (SaMD), and other MedTech products address cybersecurity requirements.

Its services include:

• Medical device penetration testing and firmware security assessments
• Application, API, and cloud security testing
• SaMD cybersecurity assessments
• FDA premarket cybersecurity support and deficiency response
• Threat modelling and security risk documentation
• SBOM and cybersecurity documentation support
• Postmarket vulnerability management
• Cybersecurity support for EU MDR and EU IVDR

Beyond identifying vulnerabilities, Medysec helps manufacturers document security findings and corrective actions. This supports regulatory review and ongoing management of device security risks.

If you are preparing a connected medical device for regulatory submission or need to assess its security, contact Medysec to discuss your testing and documentation requirements.

Conclusion

A medical device security decision can affect both hospital systems and patient treatment. That is why IoMT cybersecurity requires careful planning at every stage of a device's working life.

Healthcare organisations should focus on identifying risks early and fixing the most serious issues first. Older equipment also needs regular assessment to determine whether it remains safe to use. Clear responsibilities between manufacturers and hospital teams help prevent security concerns from going unnoticed.

With proper coordination and regular security checks, healthcare providers can reduce risks while maintaining safe patient care.

Preparing an IoMT Device for Market?

Ensure your medical device meets FDA and EU MDR cybersecurity standards before regulatory submission.

Book a Consultation →

FAQs

1. What is the difference between IoT and IoMT?

A smart thermostat falls under IoT, but a connected heart monitor belongs to IoMT. The difference is their purpose. IoMT devices collect medical information or perform functions related to patient care.

2. Why are IoMT devices vulnerable to cyberattacks?

Medical equipment often stays in hospitals for years. During that time, its software can become outdated. Security updates are not always available, leaving weaknesses that attackers can exploit.

3. How does network segmentation protect IoMT devices?

A patient monitor should not have unrestricted access to every hospital system. Network segmentation limits its connections to approved systems, making it harder for attackers to move beyond a compromised device.

4. What should healthcare organizations do if an IoMT device is compromised?

Don't unplug the equipment immediately, especially during treatment. Inform the clinical and security teams first. They should assess patient safety and arrange suitable containment with biomedical engineers before taking further action.