Cyber Risks in Connected Medical Devices (IoT & Software Exposure)

Introduction: why “connected” changes the risk picture

Connected medical devices (often called IoT medical devices) combine hardware, software, and network connectivity to monitor, diagnose, and treat patients. That connectivity can improve outcomes and reduce costs, but it also creates new ways for things to go wrong.

For UK medical device manufacturers, the challenge is not just “can someone hack it?” It’s whether a cyber incident could affect patient safety, disrupt clinical operations, expose sensitive data, or trigger regulatory and contractual issues. The good news: most risk can be reduced with clear design choices, disciplined software practices, and a realistic incident plan.

This guide breaks down the main cyber risks in connected medical devices, focusing on IoT and software exposure, and what to do about them.

What counts as a connected medical device?

A connected medical device is any device that:

• Collects or transmits data over a network (Wi‑Fi, Ethernet, Bluetooth, cellular, NFC)
• Connects to a cloud platform or mobile app
• Receives software updates remotely
• Integrates with hospital systems (for example, EPR/EMR, PACS, or device management platforms)

Examples include remote patient monitoring wearables, infusion pumps, imaging equipment with network access, smart inhalers, implant programmers, and software-driven diagnostics.

Why cyber risk is different in medical devices

In many industries, cyber incidents are “just” about data or downtime. In healthcare, the stakes can include patient harm. That changes the way risk is assessed.

Key differences include:

• Safety impact: A cyber event can affect device function, alarms, dosage, or availability.
• Long lifecycles: Devices may be used for 7–15 years, often longer than typical IT refresh cycles.
• Complex environments: Hospitals have mixed networks, legacy systems, and many third-party devices.
• Shared responsibility: Manufacturers, healthcare providers, IT teams, clinical engineering, and suppliers all influence security.

The main cyber risks (IoT & software exposure)

1) Insecure communications (data in transit)

Connected devices often send telemetry, patient data, or commands across networks. If communications are poorly protected, attackers may intercept or alter data.

Common exposures:

• Weak or missing encryption
• Poor certificate management
• Insecure Bluetooth pairing
• Hard-coded keys or shared credentials

Why it matters:

• Patient data could be exposed
• Device commands could be manipulated
• Clinical decisions could be made on altered data

Practical controls:

• Use strong encryption for all network traffic
• Implement modern authentication and certificate rotation
• Avoid shared credentials across devices
• Test pairing and onboarding flows for abuse

2) Weak authentication and access control

If a device, app, or admin portal uses weak logins, default passwords, or poor role controls, it becomes easier to gain unauthorised access.

Common exposures:

• Default credentials left in place
• No lockout or rate limiting
• Over-privileged service accounts
• Poor separation between clinical users and administrators

Practical controls:

• Enforce unique credentials and secure onboarding
• Support multi-factor authentication for admin access
• Use role-based access control (RBAC)
• Log and monitor access attempts

3) Vulnerable software dependencies and supply chain risk

Most connected devices rely on third-party libraries, operating systems, and components. Vulnerabilities in dependencies can become vulnerabilities in your product.

Common exposures:

• Outdated open-source libraries
• Unpatched embedded operating systems
• Untracked “transitive” dependencies
• Supplier firmware that cannot be updated

Practical controls:

• Maintain a software bill of materials (SBOM)
• Track vulnerabilities and patch timelines
• Vet suppliers and require security update commitments
• Design for secure updateability from day one

4) Poor patching and update mechanisms

Updates are essential, but the update process itself can be a risk if it’s not secure.

Common exposures:

• Unsigned firmware updates
• Updates delivered over insecure channels
• No rollback plan if an update fails
• Devices that cannot be updated in the field

Practical controls:

• Sign firmware and verify signatures on-device
• Use secure update channels and staged rollouts
• Provide clear update guidance for healthcare providers
• Build in safe rollback and recovery modes

5) Cloud platform and API vulnerabilities

Many devices rely on cloud services for data storage, analytics, and remote management. Weaknesses in cloud configuration or APIs can expose large volumes of data.

Common exposures:

• Misconfigured storage buckets
• Overly permissive API keys
• Insecure endpoints
• Poor tenant separation in multi-customer platforms

Practical controls:

• Apply least-privilege access policies
• Use API authentication best practices
• Pen test APIs and cloud configurations
• Monitor for unusual access patterns

6) Mobile app risk (patient and clinician apps)

Mobile apps are often the “front door” to a connected device. If the app is insecure, attackers may bypass protections or harvest data.

Common exposures:

• Weak session handling
• Sensitive data stored insecurely on the phone
• Insecure app-to-device communication
• Jailbroken/rooted device risks not considered

Practical controls:

• Secure session management and token handling
• Encrypt sensitive data at rest
• Validate device identity and pairing
• Provide clear user guidance and minimum OS requirements

7) Network exposure in clinical environments

Hospitals and clinics may connect devices to shared networks. If the device is discoverable and exposes services, it can be targeted.

Common exposures:

• Open ports and unnecessary services
• Legacy protocols
• Poor segmentation between device networks and general IT

Practical controls:

• Minimise exposed services and close unused ports
• Provide network hardening guidance to customers
• Support segmentation and device management tools

8) Ransomware and operational disruption

Even if a device is not directly “hackable”, a ransomware event in a hospital can disrupt connectivity, device management, or access to cloud dashboards.

Impacts can include:

• Loss of monitoring visibility
• Delayed procedures
• Manual workarounds and increased clinical risk

Practical controls:

• Design for safe degraded operation (fail-safe modes)
• Provide offline procedures and local controls
• Ensure clear incident communications and escalation paths

9) Data privacy and UK GDPR exposure

Connected devices may process special category health data. A breach can trigger UK GDPR reporting obligations, contractual claims, and reputational harm.

Typical data risks:

• Excessive data collection (more than needed)
• Poor retention controls
• Inadequate audit trails

Practical controls:

• Data minimisation and purpose limitation
• Strong encryption at rest and in transit
• Clear retention and deletion policies
• Accurate logging and auditability

10) Safety, liability, and product recall risk

Cyber incidents can lead to safety notices, field safety corrective actions, or recalls. Even where patient harm does not occur, the cost of investigation, remediation, and communication can be significant.

Practical controls:

• Build security into risk management and post-market surveillance
• Maintain clear vulnerability disclosure processes
• Prepare playbooks for urgent patching and customer comms

How attackers typically target connected devices

Attackers don’t always need “Hollywood hacking.” Many incidents start with basic weaknesses.

Common attack paths:

• Credential stuffing on admin portals
• Exploiting known vulnerabilities in unpatched components
• Phishing a supplier or support account
• Abusing insecure APIs
• Intercepting insecure Bluetooth or Wi‑Fi traffic

A realistic threat model should consider both opportunistic attackers and targeted attacks (for example, against high-profile healthcare providers or critical devices).

A practical risk reduction checklist for manufacturers

If you’re building or supporting connected medical devices, these steps reduce risk quickly.

Design and build

• Secure-by-design requirements from day one
• Threat modelling for device, app, cloud, and update flows
• Secure coding standards and code review
• Strong identity, authentication, and authorisation

Testing and assurance

• Regular vulnerability scanning and dependency checks
• Penetration testing across device, app, and cloud
• Secure configuration baselines
• Clear release gates for security issues

Operations and post-market

• SBOM and vulnerability management process
• Secure patching and update communications
• Incident response plan with roles and escalation
• Vulnerability disclosure policy and intake process

Customer guidance

• Installation and network hardening guidance
• Minimum supported versions and end-of-support policy
• Clear instructions for secure onboarding and password management

Where cyber insurance fits (and what it won’t do)

Cyber insurance can help with the financial impact of an incident, including specialist response support, legal advice, notification costs, and business interruption (depending on the policy). For manufacturers, it may also support liability exposures linked to data and network security events.

However, insurance is not a substitute for secure design and disciplined patching. Insurers will often expect evidence of basic controls, and claims may be affected if known vulnerabilities were ignored.

Conclusion: connectivity is a clinical advantage—if it’s managed

Connected medical devices are here to stay. The manufacturers that win long-term will be the ones that treat cyber risk as part of product quality: designing for secure updates, reducing unnecessary exposure, monitoring vulnerabilities, and communicating clearly with healthcare customers.

If you manufacture, distribute, or support connected medical devices in the UK and want to review your cyber and liability exposures, Insure24 can help you sense-check your risk profile and arrange appropriate cover.

FAQs: Cyber risks in connected medical devices

Are connected medical devices considered “IoT”?

Yes. Many connected medical devices are a form of IoT because they include sensors, software, and network connectivity. The key difference is that medical devices may have patient safety requirements and regulatory obligations.

What is the biggest cyber risk for connected medical devices?

There isn’t one single risk, but common causes include weak authentication, unpatched software dependencies, and insecure update mechanisms.

Can a cyber incident cause a medical device recall?

It can. If a vulnerability creates a safety risk or cannot be mitigated quickly, manufacturers may need to issue safety notices, field actions, or recalls depending on the circumstances.

Do hospitals handle device security, or is it the manufacturer’s job?

It’s shared. Hospitals manage their networks and operational controls, but manufacturers are responsible for secure design, patching capability, and clear guidance.

Does cyber insurance cover medical device cyber incidents?

It depends on the policy. Cyber insurance may cover incident response and certain liabilities, but product liability and professional indemnity considerations can also apply. It’s important to structure cover around your real exposures.

How can manufacturers reduce risk without slowing down development?

Build security into the development process: threat modelling, secure coding standards, dependency tracking, and repeatable testing. This usually reduces rework and improves reliability over time.

What should be included in a vulnerability disclosure process?

A clear way for researchers or customers to report issues, a triage process, timelines for response, and a plan to communicate and deploy fixes safely.

What is an SBOM and why does it matter?

An SBOM (software bill of materials) lists the software components and dependencies in your product. It helps you identify exposure when new vulnerabilities are announced and supports faster patching.