Internet of Medical Things (IoMT): Regulatory Compliance, Cybersecurity, and Market Access Guide

What Is IoMT?

The Internet of Medical Things (IoMT) refers to the interconnected ecosystem of medical devices, software applications, health systems, and communication networks that collect, transmit, and analyze healthcare data in real time. IoMT extends the broader Internet of Things (IoT) concept into clinical and patient-facing environments, where connected devices perform functions ranging from continuous physiological monitoring to automated drug delivery.

IoMT devices are distinguished from traditional medical devices by their reliance on network connectivity to deliver their intended clinical function or to transmit data that informs clinical decisions. A conventional glucometer that displays a blood glucose reading on a built-in screen is a medical device. A continuous glucose monitor (CGM) that streams glucose readings to a smartphone app, triggers alerts when levels cross thresholds, and feeds trend data into a cloud-based analytics platform is an IoMT device. The connectivity is not incidental — it is central to how the device delivers clinical value.

The scope of IoMT encompasses several device categories:

• Wearable and implantable monitors: Continuous glucose monitors, cardiac event monitors, smart patches for vital sign tracking, and implantable cardioverter-defibrillators (ICDs) with remote monitoring capabilities.
• Connected imaging systems: MRI, CT, and ultrasound systems that transmit diagnostic images to PACS (Picture Archiving and Communication Systems) and cloud-based viewing platforms.
• Networked infusion and delivery systems: Smart infusion pumps with dose error reduction software that connect to hospital formulary databases and electronic health records.
• Remote patient monitoring (RPM) platforms: Blood pressure cuffs, pulse oximeters, spirometers, and weight scales designed for home use that transmit data to clinical teams.
• Point-of-care diagnostic devices: Connected blood analyzers, portable ultrasound devices, and rapid test readers that upload results directly to laboratory information systems.
• Hospital infrastructure and asset management: Connected hospital beds, environmental monitors, medication dispensing cabinets, and real-time location systems (RTLS) for equipment tracking.
• Smart surgical systems: Robot-assisted surgical platforms that stream telemetry data, maintain cloud-connected logs, and receive software updates over network connections.

A striking indication of IoMT's penetration into healthcare infrastructure: an estimated 50-75% of connected assets in hospitals are not traditional IT equipment but smart medical and IoT devices. This means that in a typical hospital network, the majority of connected endpoints are medical devices, not servers or workstations. Each of these devices represents a potential attack surface and a regulatory compliance obligation.

IoMT Market Size and Growth

The IoMT market has grown rapidly and projections vary depending on scope and methodology. Multiple credible research firms have published sizeable estimates reflecting the transformative investment flowing into connected healthcare.

Source	2025 Estimate	Projected Value	Timeframe	CAGR
Research and Markets	$97.73 billion	$244.4 billion	by 2029	~25.7%
OpenPR / Market Research	$281.19 billion	$1,680.57 billion	by 2035	20.1%
Market.us	$48.7 billion (2022)	$370.9 billion	by 2032	23.15%

These figures should be interpreted with care. Definitions of "IoMT" vary across research firms — some include health and fitness wearables that are not regulated medical devices, while others restrict their scope to FDA- or CE-marked connected devices. Some estimates include connected hospital infrastructure (smart beds, building management systems) while others focus on direct patient care devices. Despite methodological differences, all credible projections agree on the directional trend: the IoMT market is growing at a compound annual rate of 20-26%, far outpacing the broader medical device industry's 5-6% growth rate.

Several factors drive this growth:

• Shift to value-based care: Healthcare systems are moving from fee-for-service to outcomes-based reimbursement models. Remote patient monitoring, enabled by IoMT, is central to this transition because it allows continuous health assessment without requiring in-person visits.
• Aging populations: By 2030, one in six people globally will be aged 60 or older. Chronic disease management for aging populations depends heavily on remote monitoring and connected therapeutic devices.
• Post-pandemic digital transformation: COVID-19 accelerated telehealth adoption by years. The infrastructure built for telehealth — connectivity platforms, cloud analytics, regulatory frameworks for remote care — is the same infrastructure that IoMT devices rely on.
• AI and edge computing: The ability to run AI algorithms on-device or at the network edge has expanded what IoMT devices can do, from real-time arrhythmia detection on a wearable patch to predictive maintenance alerts on imaging equipment.

How IoMT Devices Are Regulated

IoMT devices are regulated as medical devices under existing regulatory frameworks. There is no standalone "IoMT regulation" in any major jurisdiction. Instead, connected medical devices must comply with the same regulatory requirements as any other medical device, plus additional cybersecurity, data protection, and interoperability requirements triggered by their connectivity.

This layered approach means that IoMT manufacturers face a compliance stack rather than a single regulatory pathway:

Regulatory Layer	Scope	Key Requirements
Medical device regulation	Safety and effectiveness	Classification, premarket review, clinical evidence, quality system
Cybersecurity	Device and network security	Section 524B (US), CRA (EU), threat modeling, SBOM, vulnerability management
Data protection	Patient data privacy	HIPAA (US), GDPR (EU), state privacy laws
Interoperability	Data exchange standards	HL7 FHIR, IEEE 11073, DICOM
Telecommunications	Radio spectrum and EMC	FCC (US), RED Directive (EU), radio equipment compliance

In the United States, the FDA regulates IoMT devices under the same classification and premarket pathways as traditional devices: 510(k), De Novo, and PMA. The FDA's Center for Devices and Radiological Health (CDRH) and Center for Biologics Evaluation and Research (CBER) both have jurisdiction over connected devices within their respective product areas.

In the European Union, IoMT devices fall under the EU Medical Device Regulation (MDR 2017/745) or the In Vitro Diagnostic Regulation (IVDR 2017/746), classified under the existing risk classification system (Class I through III for devices, Class A through D for IVDs).

Other jurisdictions — including the UK (UKCA marking under the MRD 2002 as amended), Japan (PMDA Pharmaceutical and Medical Device Act), Australia (TGA Therapeutic Goods Act), and Canada (Medical Device Regulations) — apply their own medical device frameworks to IoMT products, with cybersecurity requirements increasingly harmonized around international standards.

Recommended Reading

Cloud-Based Medical Devices & SaaS: Regulatory Compliance Guide (FDA, EU MDR 2026)

Digital Health & AI Cybersecurity2026-04-19 · 15 min read

FDA Requirements for Connected Medical Devices

The FDA has established the most detailed regulatory framework for connected medical device cybersecurity in the world. IoMT manufacturers seeking to market devices in the United States must navigate three interlocking requirements: the statutory mandate of Section 524B, the FDA's premarket cybersecurity guidance, and the quality system requirements under the newly effective QMSR.

Section 524B and the "Cyber Device" Definition

Section 524B of the Federal Food, Drug, and Cosmetic Act, enacted through the Consolidated Appropriations Act of 2023, establishes mandatory cybersecurity requirements for what the law terms "cyber devices." The definition is deliberately broad: a cyber device is any device that (1) includes software validated, installed, or authorized by the sponsor, (2) has the ability to connect to the internet, and (3) contains technological characteristics that could be vulnerable to cybersecurity threats.

The FDA interprets "ability to connect to the internet" expansively. It encompasses not only Wi-Fi and Ethernet connections but also USB ports, Bluetooth (including BLE), serial ports (RS-232), and any other interface through which data can be transmitted. A device does not need to be actively connected to the internet in clinical use to qualify as a cyber device — it merely needs the capability. This means that the vast majority of IoMT devices fall squarely within Section 524B's scope.

For each cyber device, the sponsor must provide:

1. A cybersecurity plan describing how the manufacturer will monitor, identify, and address post-market cybersecurity vulnerabilities and exploits, including a coordinated vulnerability disclosure (CVD) process.
2. Design and development processes that provide reasonable assurance the device and related systems are cybersecure, documented as part of a Secure Product Development Framework (SPDF).
3. A commitment to make available updates and patches to address known cybersecurity vulnerabilities on a reasonably justified schedule.
4. A Software Bill of Materials (SBOM) in machine-readable format, enumerating all commercial, open-source, and off-the-shelf software components.

Failure to include this information in a premarket submission triggers a Refuse to Accept (RTA) decision — the submission is returned without review, and the regulatory timeline resets entirely.

FDA Premarket Cybersecurity Guidance (February 2026)

On February 3, 2026, the FDA issued its current operative cybersecurity guidance: "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions." This Level 2 revision supersedes the June 2025 version and was updated specifically to align with the Quality Management System Regulation (QMSR), which took effect on February 2, 2026.

The QMSR replaced 21 CFR Part 820 (the Quality System Regulation, or QSR) and incorporates ISO 13485:2016 by reference. For IoMT manufacturers, this means cybersecurity processes must now be demonstrably generated from controlled quality management system processes aligned with ISO 13485. Threat models must trace to Subclause 7.3 (design and development) controls, security validation testing must be anchored in Subclause 7.3.7 (design and development verification), and vulnerability handling must sit within Subclause 8.5 (improvement) processes.

The guidance establishes five core security objectives that every connected device must address:

Security Objective	Description
Authenticity	Verify that users, devices, and software components are what they claim to be. Includes authentication mechanisms, digital signatures, and certificate management.
Authorization	Ensure that authenticated entities can only access functions and data appropriate to their role. Includes role-based access control (RBAC), least-privilege principles, and permission management.
Availability	Ensure the device remains operational and accessible to authorized users when needed. Includes resilience against denial-of-service conditions, failover mechanisms, and recovery procedures.
Confidentiality	Protect data from unauthorized disclosure. Includes encryption of data at rest and in transit, secure key management, and data segregation.
Updatability	Enable the device to receive and apply security updates and patches. Includes secure boot mechanisms, signed firmware updates, and rollback capabilities.

For IoMT devices specifically, the guidance expects manufacturers to address additional considerations:

• Multi-device architectures: Many IoMT systems involve a constellation of devices — sensors, gateways, mobile apps, cloud backends, and clinical information systems. The cybersecurity analysis must cover the entire ecosystem, not just the primary device.
• Third-party component risks: IoMT devices frequently incorporate third-party libraries, operating systems, communication stacks, and cloud services. The manufacturer is responsible for understanding and managing the security posture of all components, including those provided by suppliers.
• Clinical network integration: Devices that connect to hospital networks must be designed to operate safely within environments that include firewalls, network segmentation, intrusion detection systems, and other security infrastructure.

Premature Submission Content for IoMT

An IoMT premarket submission must include the following cybersecurity documentation:

1. Threat model identifying assets, threat agents, attack surfaces, and attack vectors for the entire device system (hardware, software, network communications, cloud services, and mobile applications).
2. Security architecture documentation describing how the five security objectives are implemented, including data flow diagrams, trust boundaries, and cryptographic implementations.
3. SBOM for all software components in the device, including the device firmware, operating system, middleware, libraries, and any cloud-side components.
4. Cybersecurity testing evidence including penetration testing, vulnerability scanning, fuzz testing, and static and dynamic code analysis results.
5. Configuration management documentation describing how the device's security configuration can be managed in clinical environments, including hardening guides for hospital IT departments.
6. Post-market cybersecurity plan describing vulnerability monitoring, triage processes, coordinated vulnerability disclosure policy, and the process for developing and deploying patches and updates.

EU Regulatory Framework for IoMT

The European Union applies a multi-layered regulatory framework to IoMT devices. Manufacturers must navigate the EU Medical Device Regulation, emerging cybersecurity legislation, and data protection requirements simultaneously.

EU MDR Classification of Connected Devices

The EU MDR (Regulation 2017/745) does not create a separate classification category for connected devices. Instead, IoMT devices are classified under the existing risk classification system using the classification rules in Annex VIII. A connected insulin pump is classified based on its therapeutic function (typically Class IIb or III), not its connectivity. A connected blood pressure monitor for home use is classified based on its measurement function (typically Class IIa).

This approach means that connectivity features can influence classification — for example, if a software function that analyzes data from a connected sensor provides a diagnosis that would otherwise require clinical interpretation, the classification may be elevated — but connectivity alone does not determine the risk class.

The EU MDR requires all devices, including IoMT devices, to demonstrate:

• General safety and performance requirements (GSPRs) as defined in Annex I, including requirements for devices incorporating electronic programmable systems and software (GSPR 11-12, 14-17).
• Clinical evidence supporting safety and performance, proportionate to the device's risk classification.
• Post-market surveillance (PMS) plans and periodic safety update reports (PSURs) appropriate to the device's classification.
• Unique Device Identification (UDI) registration.

Cyber Resilience Act (CRA)

The EU Cyber Resilience Act, adopted in 2024 and entering into force in phases through 2027, establishes horizontal cybersecurity requirements for all products with digital elements placed on the EU market. While medical devices are already subject to sector-specific cybersecurity requirements under the MDR, the CRA applies in addition to — not in replacement of — MDR requirements for IoMT devices.

Key CRA requirements relevant to IoMT manufacturers include:

• Security by design and default: Products must be designed, developed, and produced so that they ensure an appropriate level of cybersecurity, based on the intended use and the risks.
• Vulnerability handling processes: Manufacturers must have processes for identifying, handling, and disclosing vulnerabilities throughout the product lifecycle.
• Security updates: Products must be deliverable with security updates for the expected product lifetime or for five years, whichever is shorter.
• SBOM: A software bill of materials must be available, though the CRA allows for it to be generated on demand rather than included with every shipment.
• Incident reporting: Manufacturers must report actively exploited vulnerabilities and incidents to ENISA or the relevant national CSIRT within 24 hours of becoming aware of them.

NIS2 Directive

The NIS2 Directive (Directive 2022/2555) establishes cybersecurity risk management measures and reporting obligations for entities operating in essential and important sectors, including healthcare. While NIS2 primarily targets healthcare provider organizations (hospitals, clinics, laboratories), its requirements have downstream implications for IoMT manufacturers:

• Healthcare entities must implement risk management measures that include supply chain security, meaning they will scrutinize the cybersecurity posture of IoMT devices they procure.
• Incident reporting obligations on healthcare providers create pressure on device manufacturers to provide timely vulnerability information and patches.
• NIS2's emphasis on supply chain security effectively raises the bar for IoMT manufacturers seeking to sell into EU healthcare organizations.

EUDAMED

The European Database on Medical Devices (EUDAMED) is the EU's central electronic system for registering medical devices, manufacturers, and clinical investigations. EUDAMED goes live meaningfully from May 28, 2026, when the UDI/Device Registration module becomes mandatory for all devices (including Class III, IIb, IIa, and Implantable devices). For IoMT manufacturers, this means:

• All connected devices must be registered in EUDAMED with complete UDI information.
• The device registration must accurately reflect software version information, as SBOM and versioning data are increasingly relevant for post-market traceability.
• Actor registration (manufacturer information, authorized representative details) must be completed before device registration.
• Vigilance reporting through EUDAMED's vigilance module applies to cybersecurity-related incidents, including those resulting in or contributing to serious events.

Cybersecurity Requirements for IoMT

Cybersecurity for IoMT devices is not a feature that can be bolted on at the end of development. It must be engineered into the device from the earliest design phase and maintained throughout the product lifecycle. The threat landscape for connected medical devices is severe and worsening.

The Threat Landscape

The healthcare sector experienced more ransomware attacks than any other critical infrastructure sector in 2024. Connected medical devices are attractive targets because they combine valuable data (protected health information, insurance details, payment data) with constrained computing resources that limit the security measures that can be implemented on the device itself.

In 2023, remote code execution exploits targeting medical devices surged by 437%. This dramatic increase reflects both the expanding attack surface of connected devices and the growing sophistication of threat actors targeting healthcare infrastructure. Many IoMT devices run on legacy operating systems or embedded platforms that cannot easily be patched, creating persistent vulnerabilities within hospital networks.

Threat Modeling

Threat modeling is the foundational cybersecurity activity for any IoMT device. The FDA's guidance expects manufacturers to conduct threat modeling as part of their Secure Product Development Framework (SPDF) and to document the results in premarket submissions.

An effective threat model for an IoMT device should:

1. Define the device boundary: Identify all components in the device system — the physical device, firmware, operating system, communication interfaces, mobile applications, cloud services, and any connected clinical systems.
2. Identify assets worth protecting: Patient data, device configuration data, authentication credentials, software integrity, and clinical function (the device's ability to deliver its intended therapeutic or diagnostic purpose).
3. Map attack surfaces: Network interfaces (Wi-Fi, Bluetooth, cellular, Ethernet), physical ports (USB, serial, debug interfaces), wireless protocols (BLE, Zigbee, proprietary RF), cloud APIs, mobile app interfaces, and update mechanisms.
4. Identify threat agents: Nation-state actors, organized criminal groups (particularly ransomware operators), opportunistic attackers, insider threats, and compromised supply chain components.
5. Enumerate attack vectors and scenarios: For each attack surface, describe how an attacker could compromise confidentiality, integrity, or availability, and estimate the clinical impact of successful exploitation.
6. Map mitigations to threats: For each identified threat, document the security controls implemented to reduce risk to an acceptable level, and justify any residual risk.

Common threat modeling frameworks used in medical device development include STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) and attack tree analysis.

Secure Product Development Framework (SPDF)

The FDA expects IoMT manufacturers to implement a Secure Product Development Framework — a set of integrated processes that embed cybersecurity throughout the total product lifecycle. The SPDF should address:

• Secure design principles: Least privilege, defense in depth, fail-safe defaults, secure defaults, and separation of concerns.
• Secure coding practices: Input validation, output encoding, proper error handling, secure memory management, and avoidance of known vulnerable coding patterns.
• Security testing: Static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), penetration testing, fuzz testing, and vulnerability scanning.
• Secure supply chain management: Vendor assessment, component provenance tracking, and ongoing monitoring of third-party component vulnerabilities.
• Secure deployment and configuration: Hardening guides, default security configurations, and provisioning procedures for clinical environments.

Recommended Security Frameworks and Standards

Several international standards and frameworks provide detailed guidance for implementing cybersecurity in IoMT devices:

Standard / Framework	Scope	Relevance
AAMI TIR45	Guidance on the use of agile practices for medical device software	Addresses how to incorporate cybersecurity activities into agile development workflows for connected devices
IEC 81001-5-1	Health software — Part 5-1: Security — Activities in the product lifecycle	International standard specifically addressing cybersecurity throughout the health software lifecycle, from concept through decommissioning
ANSI/ISA 62443-4-1	Secure product development lifecycle requirements for industrial automation and control systems	Provides a structured framework for secure development practices applicable to embedded medical device systems
UL 2900	Standard for software cybersecurity for network-connectable products	Recommended by IMDRF in its 2020 cybersecurity best practices document as a testing and assessment standard for medical device cybersecurity
NIST Cybersecurity Framework 2.0	Framework for improving critical infrastructure cybersecurity	Provides the organizational structure (Govern, Identify, Protect, Detect, Respond, Recover) that many healthcare organizations use to manage device security

The International Medical Device Regulators Forum (IMDRF) published cybersecurity best practices in 2020 recommending UL 2900 as a testing standard, providing international harmonization of security testing expectations for connected devices.

Security Architecture for Hospital Environments

IoMT devices do not operate in isolation — they connect to hospital networks that must themselves be secured. Key security approaches for hospitals deploying IoMT devices include:

• Zero-trust architecture: The principle of "never trust, always verify," where no device or user is inherently trusted regardless of its position on the network. Every access request must be authenticated, authorized, and continuously validated.
• Network segmentation: Separating IoMT devices onto dedicated network segments (typically VLANs) that restrict communication to only the services and endpoints required for clinical function. If a compromised device cannot reach the internet, a hospital's electronic health records, or other critical systems, the blast radius of a security incident is dramatically reduced.
• Continuous monitoring: Deploying network detection and response (NDR) tools that monitor IoMT device behavior and alert on anomalous activity, such as unexpected outbound connections, unusual data volumes, or communication with known malicious endpoints.

Recommended Reading

Wireless & RF Regulatory Compliance for Medical Devices: FCC, RED, and Global Requirements

Standards & Testing Digital Health & AI2026-04-20 · 15 min read

SBOM and Software Transparency

The Software Bill of Materials has become the centerpiece of regulatory efforts to improve software transparency in connected medical devices. For IoMT manufacturers, SBOM is no longer optional — it is a statutory requirement under Section 524B and an emerging requirement under the EU Cyber Resilience Act.

What Is an SBOM?

An SBOM is a formal, machine-readable inventory of all software components in a device, including:

• Commercial software: Proprietary operating systems, middleware, libraries, and development frameworks.
• Open-source software: Open-source libraries, frameworks, utilities, and build tools.
• Off-the-shelf software components: Third-party modules integrated into the device software.

For each component, the SBOM must include:

SBOM Element	Description
Component name	The name of the software component
Version	The specific version number or commit hash
Supplier	The vendor or open-source project that maintains the component
Relationship	How the component relates to other components (e.g., "contains," "depends on")
Support level	Whether the component is actively maintained, security-patched only, or end-of-life
End-of-support date	The date after which the supplier no longer provides security patches

SBOM Format Requirements

The FDA requires SBOMs to be machine-readable, specifically in one of two internationally recognized formats:

• CycloneDX: An OWASP Foundation standard designed specifically for security use cases, including vulnerability analysis and supply chain risk management. CycloneDX is lightweight, supports dependency graphs, and is widely adopted in the medical device industry.
• SPDX (Software Package Data Exchange): A Linux Foundation standard for communicating software bill of materials information. SPDX provides a standardized format for documenting software components, licenses, and copyrights.

Both formats are ISO standards (CycloneDX as ISO/IEC 5962, SPDX as ISO/IEC 5692) and are accepted by the FDA.

SBOM in Practice

For IoMT manufacturers, producing and maintaining accurate SBOMs requires investment in tooling and process:

• Automated generation: SBOMs should be generated automatically during the build process using tools that scan the source code repository, build artifacts, and container images. Manual SBOM creation is error-prone and unsustainable for devices with hundreds of components.
• Vulnerability correlation: Once generated, the SBOM must be correlated against known vulnerability databases (NVD, CVE) to identify components with published vulnerabilities. This correlation must be repeated on an ongoing basis as new vulnerabilities are disclosed.
• Risk triage: Not every vulnerability in an SBOM requires immediate action. Manufacturers must triage vulnerabilities based on exploitability (is there a known exploit?), clinical impact (could exploitation affect patient safety?), and compensating controls (are there mitigating factors in the device's security architecture?).
• Lifecycle management: SBOMs must be updated with each software release. When a component reaches end-of-life and no longer receives security patches, the manufacturer must assess the risk and either update to a supported version or implement compensating controls.

Post-Market Surveillance for Connected Devices

Post-market cybersecurity obligations for IoMT devices are not merely best practice — they carry independent legal enforcement weight. Under Section 301(q) of the FD&C Act, failure to maintain cybersecurity measures after market authorization constitutes a prohibited act, giving the FDA enforcement authority independent of the premarket RTA mechanism.

Vulnerability Monitoring

IoMT manufacturers must implement continuous vulnerability monitoring processes:

1. Subscribe to vulnerability databases: Monitor the National Vulnerability Database (NVD), ICS-CERT advisories, and vendor-specific security advisories for vulnerabilities affecting components in the device's SBOM.
2. Monitor threat intelligence feeds: Track healthcare-specific threat intelligence sources for emerging attack patterns targeting medical devices.
3. Internal vulnerability discovery: Conduct periodic security testing (penetration testing, vulnerability scanning) on marketed devices to identify previously unknown vulnerabilities.
4. Coordinated vulnerability disclosure (CVD): Maintain a publicly accessible mechanism for external security researchers to report vulnerabilities. The CVD policy must define the process for receiving reports, communicating with researchers, validating findings, and coordinating the timing of public disclosure with patch availability.

Patch Management

Deploying security patches to IoMT devices in clinical environments presents unique challenges that traditional IT patch management does not face:

• Clinical validation: Unlike an IT server, a medical device patch must be validated to confirm it does not alter the device's clinical performance. A patch that fixes a buffer overflow but subtly changes the filtering algorithm in a patient monitor could have patient safety consequences.
• Change control: Under the QMSR (and ISO 13485), software changes to marketed devices must go through a controlled change management process, which may include design verification, design validation, risk analysis updates, and regulatory assessment.
• Scheduling constraints: Hospitals cannot always take devices offline for patching immediately. Critical care devices (ventilators, infusion pumps, monitors in ICU) may need to be patched on a rolling basis during planned maintenance windows.
• Legacy device support: Many IoMT devices in clinical use run on operating systems that are no longer supported by their original vendor (e.g., Windows 7, older Linux kernels). Patching these devices may require backporting security fixes or implementing compensating controls.

Coordinated Vulnerability Disclosure

Every IoMT manufacturer must maintain a coordinated vulnerability disclosure (CVD) policy. This policy should:

• Provide a clear mechanism for external parties to report vulnerabilities (a dedicated email address, web form, or vulnerability disclosure platform such as HackerOne or Bugcrowd).
• Commit to acknowledging receipt of vulnerability reports within a defined timeframe (typically 3-5 business days).
• Describe the process for validating reported vulnerabilities and communicating with the reporter.
• Define the timeline for developing and deploying fixes, with interim guidance for affected users when a fix cannot be deployed immediately.
• Coordinate with CISA, ICS-CERT, or the relevant national cybersecurity authority for vulnerabilities with broad impact.

Privacy and Data Protection

IoMT devices generate, transmit, and store vast quantities of health data. A continuous glucose monitor may generate 288 glucose readings per day. A remote cardiac monitor may produce continuous ECG data for weeks. A connected hospital infusion system may record every dose administered to every patient across an entire ward. Each of these data flows triggers privacy and data protection obligations.

HIPAA (United States)

The Health Insurance Portability and Accountability Act (HIPAA) applies to IoMT manufacturers when they act as business associates of covered entities (hospitals, health plans, healthcare providers). Key HIPAA requirements for IoMT include:

• Business Associate Agreements (BAAs): IoMT manufacturers that create, receive, maintain, or transmit protected health information (PHI) on behalf of a covered entity must execute a BAA that governs the permitted uses and disclosures of PHI.
• Security Rule: Implement administrative, physical, and technical safeguards to protect electronic PHI (ePHI). For IoMT devices, this includes encryption of data at rest and in transit, access controls, audit logging, and integrity controls.
• Breach notification: If unsecured PHI is breached, the manufacturer (as a business associate) must notify the covered entity without unreasonable delay, and the covered entity must notify affected individuals and HHS.
• Risk analysis and risk management: Conduct a thorough risk analysis of the device and its data handling practices, and implement a risk management plan to address identified risks.

The HIPAA Security Rule NPRM, proposed in early 2026, would mandate specific technical controls including encryption, multi-factor authentication, network segmentation, and 24-hour incident notification — requirements that, if finalized, would raise the compliance bar significantly for IoMT manufacturers.

GDPR (European Union)

The General Data Protection Regulation applies to IoMT devices that process personal data of individuals in the European Economic Area. Health data is classified as a "special category" of personal data under GDPR, requiring additional protections:

• Lawful basis for processing: IoMT manufacturers must establish a lawful basis for processing health data, typically explicit consent or necessity for healthcare provision.
• Data protection by design and by default: Privacy must be embedded into the device's design, including data minimization (collecting only what is necessary), purpose limitation, and storage limitation.
• Data subject rights: Individuals have the right to access, rectify, erase, and port their data. IoMT systems must be designed to support these rights.
• Data protection impact assessment (DPIA): Required when processing health data at scale, which many IoMT platforms do.
• International data transfers: If IoMT data is transferred outside the EEA (e.g., to a cloud platform hosted in the United States), the manufacturer must ensure adequate safeguards are in place, such as Standard Contractual Clauses (SCCs) or the EU-US Data Privacy Framework.

US State Privacy Laws

Beyond HIPAA, an increasing number of US states have enacted comprehensive consumer privacy laws that may apply to IoMT data when it falls outside HIPAA's scope (e.g., data collected from direct-to-consumer devices, wellness data not covered by HIPAA, or data shared with non-covered third parties). States with comprehensive privacy laws as of 2026 include California (CCPA/CPRA), Virginia, Colorado, Connecticut, Utah, Iowa, Indiana, Tennessee, Montana, Texas, Oregon, Delaware, New Hampshire, New Jersey, Maryland, Minnesota, Nebraska, and others.

Recommended Reading

HIPAA Compliance for Medical Device Companies (2026 Security Rule Update)

Cybersecurity Digital Health & AI2026-04-19 · 18 min read

Interoperability Standards

Interoperability — the ability of IoMT devices and health information systems to exchange and use data seamlessly — is both a market requirement and a regulatory expectation. Without interoperability, connected devices create data silos that undermine the clinical value of connectivity.

HL7 FHIR (Fast Healthcare Interoperability Resources)

HL7 FHIR has become the dominant standard for healthcare data exchange. For IoMT manufacturers, FHIR provides:

• Standardized resource definitions: Patient, Observation, Device, and DeviceMetric resources allow IoMT devices to represent clinical data in a format that any FHIR-compliant system can consume.
• RESTful APIs: FHIR's REST-based interface simplifies integration with electronic health records, clinical decision support systems, and health information exchanges.
• Payload profiles: The IoMT Implementation Guide, developed under HL7, defines profiles for representing IoMT device data (observations, device characteristics, measurements) as FHIR resources.

The 21st Century Cures Act's information blocking provisions (enforced by ONC) effectively mandate that healthcare providers use standardized APIs (primarily FHIR) for patient data access, creating market demand for FHIR-native IoMT devices.

IEEE 11073 (Medical Device Communication)

IEEE 11073 is a family of standards for medical device communication, defining how medical devices exchange data with other systems at the transport and device specialization layers:

• IEEE 11073-10101: Nomenclature for medical device communication, providing standardized codes for measurements, units, and alerts.
• IEEE 11073-104xx: Device specialization standards for specific device types (e.g., 10407 for blood pressure monitors, 10408 for thermometers, 10415 for weighing scales, 10417 for glucose monitors, 10420 for pulse oximeters).
• IEEE 11073-20601: Transport layer protocol optimized for medical device communication, including support for Bluetooth and USB transport.

For IoMT manufacturers targeting the connected home health market (remote patient monitoring, chronic disease management), IEEE 11073 compliance enables plug-and-play interoperability with a wide range of health platforms.

Additional Interoperability Considerations

• DICOM: Connected imaging devices must support DICOM (Digital Imaging and Communications in Medicine) for image storage, retrieval, and transmission.
• Bluetooth Medical Device Profile (HDP): The Bluetooth Health Device Profile provides a standard transport protocol for medical device data over Bluetooth, enabling interoperability between devices and health platforms.
• Cloud connectivity standards: As IoMT devices increasingly connect to cloud platforms, manufacturers must consider API security, authentication, and data format standardization.

Risk Classification of IoMT Devices

The following table summarizes typical risk classifications for common IoMT device categories across major jurisdictions. Actual classification depends on the specific intended use, indications for use, and features of each device.

IoMT Device Category	Typical FDA Class	Typical EU MDR Class	Key Regulatory Considerations
Remote patient monitoring (BP, SpO2, weight)	Class II (510(k))	Class IIa	Data accuracy, cybersecurity, wireless coexistence
Continuous glucose monitors (CGM)	Class II (De Novo/510(k))	Class IIb	Software algorithm validation, cybersecurity, interoperability
Connected insulin pumps (AID systems)	Class II or III (De Novo/PMA)	Class IIb or III	Closed-loop algorithm, cybersecurity, interoperability, clinical evidence
Connected cardiac implantables (ICD, pacemaker)	Class III (PMA)	Class III	RF cybersecurity, battery management, remote monitoring data integrity
Smart infusion pumps	Class II (510(k))	Class IIa or IIb	Dose error reduction software, network integration, cybersecurity
Connected imaging systems (MRI, CT, ultrasound)	Class II or III (510(k)/PMA)	Class IIa or IIb	DICOM integration, image data security, AI algorithm governance
Telehealth platforms with diagnostic functions	Class II (510(k))	Class IIa	Software as medical device, data privacy, real-time performance
Connected point-of-care diagnostic devices	Class II (510(k))	Class IIa	Data accuracy, interoperability (LIS integration), cybersecurity
Hospital asset management / RTLS	Generally Class I (if regulated)	Class I	Generally not regulated as medical device unless clinical function claimed
Wearable cardiac monitors (Holter, event)	Class II (510(k))	Class IIa	Arrhythmia detection algorithm, data transmission security
Connected medication dispensing cabinets	Class I or II	Class I or IIa	Access control, audit logging, formulary management integration
AI-powered diagnostic software (cloud-based)	Class II (510(k)/De Novo)	Class IIa or IIb	Software lifecycle management, performance over time, bias monitoring

Classification is always determined by the specific intended use and technological characteristics of the individual device. The table above provides general guidance — consult the relevant regulatory authority for device-specific classification decisions.

IoMT Compliance Checklist for Manufacturers

The following checklist provides a structured approach to IoMT regulatory compliance. It is organized in the approximate order in which activities should be performed during product development.

1. Determine regulatory classification early. Before writing code, determine your device's FDA classification (Class I, II, or III), EU MDR risk class (I, IIa, IIb, III), and corresponding premarket pathway. Classification drives every subsequent compliance decision.

2. Establish a Secure Product Development Framework (SPDF). Document the processes that will embed cybersecurity into every phase of development — from requirements gathering through design, implementation, testing, and release. Align the SPDF with ISO 13485:2016 processes as required by QMSR.

3. Conduct threat modeling. Perform a comprehensive threat model covering all device system components, including the physical device, firmware, mobile applications, cloud services, and network communications. Document assets, threat agents, attack surfaces, attack vectors, and mitigations.

4. Design security architecture. Implement controls addressing all five FDA security objectives: authenticity, authorization, availability, confidentiality, and updatability. Document the architecture with data flow diagrams, trust boundaries, and cryptographic implementations.

5. Implement SBOM generation. Integrate automated SBOM generation into your build pipeline using CycloneDX or SPDX format. Ensure the SBOM includes component names, versions, suppliers, relationships, support levels, and end-of-support dates.

6. Select and validate interoperability standards. Determine which interoperability standards apply to your device (HL7 FHIR, IEEE 11073, DICOM, Bluetooth HDP) and validate conformance through testing.

7. Conduct security testing. Perform static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), penetration testing, fuzz testing, and vulnerability scanning. Document all findings, risk assessments, and mitigations.

8. Develop a post-market cybersecurity plan. Document your processes for vulnerability monitoring, triage, coordinated vulnerability disclosure, and patch development and deployment. Define timelines and escalation criteria.

9. Establish a coordinated vulnerability disclosure (CVD) program. Create a publicly accessible mechanism for receiving vulnerability reports from external researchers. Define the process for acknowledgment, validation, communication, and coordinated disclosure.

10. Assess privacy obligations. Determine which privacy frameworks apply (HIPAA, GDPR, state privacy laws), conduct a privacy impact assessment, implement data protection measures, and execute necessary agreements (BAAs, data processing agreements).

11. Prepare premarket submission documentation. Compile the cybersecurity documentation required for your submission type: threat model, security architecture, SBOM, testing evidence, configuration management documentation, and post-market cybersecurity plan.

12. Register in EUDAMED (for EU market). Complete actor registration (manufacturer, authorized representative) and device registration with UDI information. Ensure registration is completed before placing the device on the EU market.

13. Implement post-market surveillance. After market authorization, activate your post-market cybersecurity plan: monitor vulnerability databases, conduct periodic security testing, track field complaints related to cybersecurity, and update the SBOM with each software release.

14. Plan for regulatory change. Monitor evolving cybersecurity regulations (CRA implementation timelines, NIS2 enforcement, HIPAA Security Rule updates) and update your compliance program proactively rather than reactively.

Recommended Reading

Mobile Medical Applications: FDA & EU MDR Regulatory Guide (2026)

Digital Health & AI Regulatory2026-04-19 · 17 min read

Common Pitfalls and How to Avoid Them

IoMT manufacturers frequently encounter the following compliance challenges. Understanding these pitfalls can help avoid costly delays and regulatory setbacks.

Treating Cybersecurity as a Last-Minute Add-On

The most common and most consequential mistake. Manufacturers who defer cybersecurity to the end of development discover that retrofitting security controls into an architecture not designed for security is exponentially more expensive and less effective than building security in from the start. Threat modeling should begin in the concept phase. Security architecture should be defined alongside functional architecture. Security testing should be integrated into the development pipeline, not conducted as a one-time audit before submission.

Incomplete SBOMs

Many manufacturers generate SBOMs that capture only top-level dependencies while missing transitive dependencies (libraries used by libraries). An incomplete SBOM provides a false sense of security and fails to meet regulatory requirements. Automated SBOM generation tools must be configured to capture the full dependency tree, and the output should be validated against the actual build artifacts.

Ignoring the Cloud and Mobile Components

The FDA's cybersecurity guidance applies to the entire device system, not just the physical device. Many manufacturers focus their cybersecurity efforts on the embedded device while neglecting the mobile application, cloud backend, and API layer. A threat model that only covers the physical device is an incomplete threat model. The SBOM must cover all system components. Security testing must include the mobile app and cloud services.

Underestimating Post-Market Obligations

Market authorization is the beginning of the compliance journey, not the end. Section 301(q) of the FD&C Act gives the FDA independent enforcement authority for post-market cybersecurity failures. IoMT manufacturers must maintain vulnerability monitoring, issue patches and updates, and operate their CVD program throughout the device's market lifetime. Budgeting and resourcing for post-market cybersecurity must be planned from the start.

Neglecting Interoperability Testing

Interoperability is a market access requirement masquerading as a technical feature. Devices that cannot exchange data with hospital information systems, EHRs, and other connected devices may be clinically effective but commercially nonviable. Interoperability testing should be conducted against representative clinical environments early in development, not as a pre-launch checklist item.

Confusing "Connected" with "Secure"

Adding a Wi-Fi module to a device does not make it an IoMT device — but it does make it a regulated cyber device under Section 524B. Manufacturers who add connectivity features without a corresponding investment in cybersecurity architecture, threat modeling, and security testing face regulatory rejection and, more importantly, create devices that endanger patients.

Inadequate Privacy Analysis

IoMT devices often collect more data than is strictly necessary for their clinical function. Under GDPR's data minimization principle and HIPAA's minimum necessary standard, collecting excessive data is itself a compliance failure. Privacy analysis should be conducted early, alongside security analysis, to ensure the device collects only what it needs, stores it only as long as necessary, and protects it appropriately.

The Future of IoMT Regulation

The regulatory landscape for IoMT continues to evolve rapidly. Several trends will shape compliance requirements over the coming years:

Harmonization of International Cybersecurity Standards

The IMDRF's work on cybersecurity best practices, combined with the adoption of IEC 81001-5-1 as an international standard, is driving convergence across jurisdictions. Japan has already mandated IEC 81001-5-1 compliance, and other regulators are expected to follow. Manufacturers who build their cybersecurity programs around internationally recognized standards will be best positioned to meet requirements across multiple markets.

Artificial Intelligence in IoMT

The integration of AI/ML capabilities into IoMT devices creates additional regulatory complexity. AI-powered diagnostic algorithms running on connected devices must comply with both the FDA's AI/ML framework (including predetermined change control plans) and the cybersecurity requirements triggered by connectivity. The intersection of AI adaptability and cybersecurity assurance — ensuring that an AI model has not been tampered with, that its inputs are authentic, and that its outputs are trustworthy — is an emerging area of regulatory attention.

Expanded SBOM Requirements

The EU Cyber Resilience Act, once fully enforced, will require SBOMs for all products with digital elements, not just medical devices. This creates a broader supply chain transparency requirement that IoMT manufacturers must meet for both their medical device and non-device software components. Additionally, the healthcare sector is moving toward automated SBOM consumption, where hospital IT systems ingest SBOMs from deployed devices and automatically cross-reference them against vulnerability databases in real time.

Real-Time Post-Market Monitoring

Regulators are moving toward expecting real-time or near-real-time post-market cybersecurity monitoring. Rather than periodic vulnerability scans and annual security assessments, the trajectory points toward continuous monitoring of device behavior in clinical environments, automated vulnerability alerting based on SBOM correlation, and rapid (measured in days, not months) patch deployment for critical vulnerabilities.

Privacy-Preserving Technologies

The tension between the data-hungry nature of AI-powered IoMT devices and increasingly strict privacy regulations will drive adoption of privacy-preserving technologies: federated learning (training AI models across distributed datasets without centralizing patient data), differential privacy (adding calibrated noise to datasets to prevent individual re-identification), and homomorphic encryption (performing computations on encrypted data without decrypting it). Manufacturers who invest in these technologies will have a compliance advantage.

Regulatory Capacity and Enforcement

The FDA and EU authorities are expanding their capacity to review and enforce cybersecurity requirements. The FDA's Refuse to Accept policy for missing cybersecurity documentation is now well established, and the DOJ's Civil Cyber-Fraud Initiative has demonstrated willingness to use the False Claims Act to pursue cybersecurity failures in federally funded healthcare programs. The Illumina $9.8 million settlement in 2025 was the first False Claims Act case for medical device cybersecurity, and the DOJ recovered $52 million across nine cybersecurity-related False Claims Act settlements in fiscal year 2025. This enforcement trajectory is expected to continue and intensify.

Key Takeaways

IoMT regulation is not a single requirement but a compliance stack that layers medical device regulation, cybersecurity mandates, data protection law, and interoperability standards. The key principles for manufacturers are:

• Design security in from the start. Threat model early, architect for security, and integrate security testing into your development pipeline. Retrofitting security is expensive and ineffective.
• Understand Section 524B is law, not guidance. If your device is a cyber device — and most IoMT devices are — SBOM, post-market plans, and CVD policies are statutory requirements that the FDA cannot waive.
• Plan for the lifecycle, not just the launch. Post-market cybersecurity obligations carry independent enforcement authority. Budget and resource your vulnerability management, patch development, and CVD operations for the entire market lifetime of the device.
• Build for interoperability. HL7 FHIR, IEEE 11073, and DICOM conformance is not optional — it is how your device delivers clinical value in connected healthcare environments.
• Address privacy alongside security. HIPAA, GDPR, and state privacy laws apply to the health data your device generates and transmits. Privacy analysis and security analysis should proceed in parallel.
• Monitor the regulatory horizon. The CRA, NIS2, HIPAA Security Rule updates, and international cybersecurity standardization efforts are all in motion. Compliance is a moving target — your program must be designed to adapt.

The IoMT market is growing at a rate that demands both innovation and discipline. The manufacturers who succeed will be those who treat regulatory compliance not as a barrier to market access but as a competitive advantage — demonstrating to regulators, healthcare providers, and patients that their connected devices are designed, built, and maintained to the highest standards of safety, security, and effectiveness.