Digital trust for connected medical devices and IoMT security

At a glance

What this is: This is a DigiCert analysis of how digital trust supports connected medical devices and IoMT security, with the key finding that certificate-backed device identity and policy enforcement are central to safer operation.

Why it matters: It matters because device identity, lifecycle control, and secure integration patterns in IoMT map directly to the same governance challenges that IAM, PAM, and NHI teams face across connected environments.

By the numbers:

• The global IoMT market will surge to almost $188 billion by 2028, quadrupling its value from 2020.
• 70.6 million Americans will use remote patient monitoring solutions by 2025, a 56.5% jump from 2022.
• A 2022 FBI report cited research showing that 53% of connected and IoT devices in hospitals had known vulnerabilities.
• 6.2 vulnerabilities

👉 Read DigiCert's blog on digital trust for connected medical devices

Context

Connected medical devices are a device identity and trust problem as much as a clinical technology problem. When pumps, pacemakers, monitoring systems, and EHR integrations communicate across networks, the security question becomes whether the device can be authenticated, updated, and constrained across its full operating life.

For IAM and NHI teams, the important shift is that each device behaves like a managed identity with credentials, policy, and lifecycle obligations. The article argues that digital trust, especially certificate-based authentication and secure update handling, is what allows those obligations to be enforced consistently across manufacturing, deployment, and hospital operation.

Key questions

Q: How should healthcare organisations govern connected medical devices as identities?

A: Treat each connected device as a non-human identity with an owner, credentials, policy boundaries, and a lifecycle. That means enrollment, authentication, certificate renewal, integration control, and retirement should be governed together, not handled as separate IT tasks. The goal is to keep device trust provable from manufacturing through bedside use.

Q: Why do connected medical devices create identity security risk for hospitals?

A: Because they combine long lifetimes, network connectivity, and clinical dependencies, which makes trust failures hard to see and expensive to contain. If a device can authenticate poorly, integrate widely, or remain unpatched at end of life, it can become both an entry point and a multiplier for operational disruption.

Q: What breaks when IoMT device trust is managed manually?

A: Manual trust management breaks at scale because certificates, integrations, and patch status drift faster than teams can track them. Inconsistent connectivity, diverse device models, and custom cloud code create exceptions that are difficult to reconcile, which is how unmanaged identity risk accumulates.

Q: How should teams reduce the blast radius of a compromised medical device?

A: Constrain what each device can reach, what data it can influence, and which downstream systems will trust its output. The safest model is to pair identity assurance with least privilege at the integration layer, so compromise of one device does not automatically spread into broader clinical systems.

Technical breakdown

Device identity and certificate-based authentication in IoMT

Connected medical devices need a stable way to prove who they are before they exchange data or accept commands. In IoMT, that usually means certificates and device identity controls rather than shared passwords or ad hoc trust. The article’s point is that device authenticity matters from the factory floor through bedside operation, because counterfeiting, impersonation, and tampering all depend on weak identity assurance. When device identity is not provable, policy cannot reliably distinguish a legitimate infusion pump from a compromised or cloned one.

Practical implication: treat IoMT devices as identities that must be enrolled, authenticated, and governed before they are allowed to operate.

Encrypted telemetry, integrity, and integration risk

IoMT systems often move sensitive patient data between devices, hospital networks, cloud services, and operational platforms. Digital certificates help protect both confidentiality and integrity, which means they reduce the risk of interception, tampering, and unsafe data injection during transmission. The article also points to integration complexity, where custom code and cloud APIs can create maintenance-heavy trust paths. In practice, every new integration adds another place where identity assurance and trust enforcement can fail if not centrally managed.

Practical implication: review every device-to-cloud and device-to-device integration as an identity boundary, not just a connectivity project.

Lifecycle control for devices that outlive their security posture

Connected medical devices have long lifetimes, but their trust posture can degrade faster than their clinical usefulness. Intermittent connectivity, patch constraints, and diverse product lines make it difficult to keep certificates, policies, and security updates aligned over time. That creates a lifecycle gap: a device may remain in service long after its identity controls, firmware support, or update channel have become fragile. The article shows why device trust has to include provisioning, rotation, and update handling, not only initial enrollment.

Practical implication: build device lifecycle governance that covers provisioning, certificate renewal, patching, and end-of-life retirement together.

Threat narrative

Attacker objective: The attacker aims to manipulate or interrupt connected medical device operations in ways that harm patients, disrupt care, or expose sensitive health data.

1. Entry occurs when an attacker targets the connected medical device itself or the network path around it, using weak device trust, exposed integrations, or vulnerable hospital infrastructure to reach the environment.
2. Escalation follows when compromised device access is used to tamper with telemetry, disrupt patient data flow, or influence connected systems that depend on the device for safe operation.
3. Impact occurs when patient data is compromised, device behavior is altered, or care delivery is disrupted across linked hospital systems and medical devices.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Digital trust for IoMT is device identity governance, not a narrow product feature. The article shows that connected medical devices must be authenticated, encrypted, updated, and retired under policy, which places them squarely inside identity governance. That matters because the control problem is not only transport security but trust continuity across the full device lifecycle. Practitioners should treat every connected device as a governed identity with operational consequences.

The Ultimate Guide to NHIs , Why NHI Security Matters Now: IoMT devices fit the broader NHI pattern of high-volume, high-dependence identities that outnumber human accounts and are often poorly governed. Once devices are connected to clinical workflows, their credentials, certificates, and integrations become part of the enterprise attack surface. The implication is that healthcare teams cannot separate medical device security from identity lifecycle discipline.

Identity blast radius is the right concept for connected medical devices. A compromised device does not only affect one endpoint if it feeds telemetry, alerts, and automation into wider clinical systems. The blast radius expands through trusted integrations, which means the security question is how far a single device identity can influence downstream systems. Practitioners should map and constrain that blast radius before it becomes a patient-safety issue.

52 NHI Breaches Analysis: The recurring lesson across machine identity incidents is that exposed credentials and weak governance turn ordinary systems into high-impact breach paths. IoMT changes the stakes because the affected assets are clinical, but the governance failure is familiar: trust was assumed rather than continuously proven. Security teams should evaluate connected devices with the same rigor they apply to other non-human identities.

Centralised certificate and policy management is becoming a baseline expectation for regulated device ecosystems. The article’s discussion of intermittent connectivity, diverse device lines, and cloud integration shows why manual trust handling does not scale. The practical conclusion is that healthcare organisations need policy consistency across device classes, or they will accumulate unmanaged trust exceptions that become security debt.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Healthcare teams should use Ultimate Guide to NHIs , Why NHI Security Matters Now to connect device trust with lifecycle governance and operational risk.

What this signals

Device trust is converging with NHI governance. Connected medical devices are not just endpoints, they are credentialed actors whose behaviour must be governed over time. For teams running clinical platforms, that means the same lifecycle questions applied to service accounts now apply to pumps, monitors, gateways, and cloud-connected device fleets.

The stronger the clinical integration, the more important the trust boundary becomes. If device identity, certificate renewal, and integration scopes are not centrally governed, the result is a growing set of exceptions that no one can confidently audit or revoke.

Healthcare security programmes should expect more pressure to prove device authenticity, updateability, and retirement control. Organisations that can tie device identity to policy and evidence will be better positioned to manage both patient-safety risk and compliance expectations.

For practitioners

• Map every connected device as a governed identity Inventory pumps, monitors, gateways, and integrations as identity-bearing assets with owners, certificates, and renewal dates. Include manufacturing, deployment, and retirement states so the device lifecycle is visible end to end.
• Enforce certificate-backed authentication for device trust Require provable device identity before telemetry exchange, command acceptance, or clinical integration. Replace shared trust assumptions with certificate-based controls that can be revoked when a device or vendor relationship changes.
• Review cloud and EHR integrations as trust boundaries Audit every API and cloud connection that carries device data into clinical workflows. Limit what each integration can read or influence, and document the failure mode if that trust path is disrupted.
• Build lifecycle controls for patching and end-of-life retirement Track certificate renewal, firmware updates, and end-of-life status together. If a device cannot be patched or revalidated on a schedule that matches its clinical use, plan its replacement before security debt accumulates.

Key takeaways

• Connected medical devices create an identity governance problem because device trust must be maintained across manufacturing, deployment, integration, and retirement.
• The article’s risk signals are material, with hundreds of vulnerabilities and large-scale IoMT growth showing that exposed device identity is already an operational reality.
• Teams should centralise device identity, enforce certificate-backed trust, and manage lifecycle controls as part of clinical security, not as an afterthought.

Key terms

• Internet of Medical Things: Internet of Medical Things, or IoMT, refers to connected medical devices that exchange data with hospital systems, cloud services, or patient monitoring platforms. These devices create both clinical value and security risk because they depend on identity, connectivity, and lifecycle control to operate safely over time.
• Device Trust: Device trust is the assurance that a device is genuine, authorised, and behaving within policy before it is allowed to exchange data or receive commands. In identity terms, it is the combination of authentication, encryption, policy enforcement, and revocation that keeps machine interactions reliable.
• Certificate Lifecycle: Certificate lifecycle is the process of issuing, renewing, rotating, and revoking digital certificates as trust requirements change. For connected medical devices, lifecycle discipline is critical because stale certificates can outlive the device state they were meant to protect.
• Identity Blast Radius: Identity blast radius is the amount of downstream access, influence, or disruption that a single compromised identity can create. For connected devices, the blast radius grows when telemetry, automation, and clinical systems trust one device output too broadly.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Digital Trust for connected medical devices. Read the original.