Regulatory Frameworks for IoT in Healthcare

• IoMT Overview: IoMT (Internet of Medical Things) connects devices like wearables, sensors, and cloud platforms to collect and share patient data. Examples include heart monitors and virtual care platforms.
• Why Regulations Are Crucial: IoT devices in healthcare face rising cyber threats. In 2023, attacks on medical devices increased by 437%. Regulations ensure device safety, data security, and patient privacy.
• Key Regulatory Areas:
  • Device Safety: FDA classifies devices by risk (Class I, II, III) and requires premarket reviews.
  • Cybersecurity: Manufacturers must submit cybersecurity plans, including vulnerability management and SBOM (Software Bill of Materials).
  • Data Privacy: HIPAA and GDPR govern how patient data is handled and protected.
  • Interoperability: Standards like HL7 FHIR ensure seamless data exchange.

U.S. & Global Highlights:

• FDA Changes: Effective February 2026, the FDA adopted QMSR, aligning with ISO 13485 for global compliance.
• HIPAA Updates: Encryption is now mandatory for protecting electronic Protected Health Information (ePHI).
• EU MDR & GDPR: IoT devices in Europe must meet stricter safety and data residency rules.
• Cybersecurity Laws: The EU Cyber Resilience Act mirrors U.S. SBOM requirements, emphasizing secure design and updates.

Compliance Is Lifelong:

From design to decommissioning, IoT devices must meet safety, security, and privacy standards. Continuous monitoring, risk management, and audit-ready documentation are critical for maintaining compliance. This is especially true as organizations work toward taking the risk out of healthcare through better visibility into clinical application and device uptime.

U.S. Regulatory Requirements for Healthcare IoT

FDA Oversight of IoT Medical Devices

The FDA categorizes IoT medical devices based on the level of risk they pose, assigning them to one of three classes. Class I devices, which carry the lowest risk, are subject to minimal controls. Class II devices require a 510(k) premarket notification, proving they are "substantially equivalent" to an already-approved device. For Class III devices, which pose the highest risk, manufacturers must provide valid scientific evidence of safety and effectiveness through Premarket Approval (PMA). If a device is novel and lacks a predicate, the De Novo pathway allows low-to-moderate risk devices to enter the market.

A major regulatory shift occurred on February 2, 2026, when the FDA replaced the Quality System Regulation (QSR) with the Quality Management System Regulation (QMSR). QMSR incorporates ISO 13485:2016, aligning U.S. quality standards with international benchmarks. This change helps manufacturers streamline compliance, especially those operating globally. Many organizations are also adopting a cybersecurity program for digital health innovators to ensure long-term resilience. Additionally, IoT devices must include a Unique Device Identifier (UDI) for improved patient safety tracking and post-market monitoring.

Connected devices face additional scrutiny under Section 524B of the FD&C Act, introduced through the Consolidated Appropriations Act of 2023. This law defines any internet-connected device (including those using Bluetooth or USB) with potential cyber vulnerabilities as a "cyber device." Cyber device manufacturers must submit a Cybersecurity Plan, a Software Bill of Materials (SBOM), and a Product Development Framework (SPDF) with their premarket applications. Failing to include these can result in a "Refuse to Accept" (RTA) decision, which delays the approval process. While the FDA oversees device safety and cybersecurity, HIPAA governs how sensitive data generated by these devices is handled.

HIPAA Compliance for IoT-Generated Data

HIPAA regulations kick in as soon as an IoT device interacts with electronic Protected Health Information (ePHI). Covered entities, such as hospitals and clinics, and their business associates (third-party vendors handling ePHI) must implement safeguards across three categories:

• Administrative: Policies and staff training.
• Physical: Controls to restrict device access.
• Technical: Encryption, audit logs, and access management.

In January 2025, the Department of Health and Human Services (HHS) proposed updates to the HIPAA Security Rule to address evolving cybersecurity threats. These updates include requiring organizations to inventory IoT devices and map ePHI data flows. Encryption, previously an "addressable" option, is becoming a firm requirement for both stored and transmitted ePHI due to its widespread adoption in modern systems.

"The proposals in this NPRM would increase the cybersecurity for ePHI by revising the Security Rule to address: changes in the environment in which health care is provided; significant increases in breaches and cyberattacks; [and] common deficiencies the Office for Civil Rights has observed." - Office for Civil Rights (OCR), HHS ^[6]

IoT vendors handling ePHI for healthcare providers are considered business associates and must sign a Business Associate Agreement (BAA). This agreement makes them directly responsible for HIPAA compliance, not just the healthcare provider.

Where FDA and HIPAA Requirements Overlap

The overlap between FDA and HIPAA requirements highlights the interconnected nature of device safety and data security. A cyberattack on a connected medical device can create dual compliance challenges: compromising the device's clinical function (an FDA issue) and exposing patient data (a HIPAA issue). Between mid-2020 and 2021, 82% of healthcare systems reported a cyber incident, with 34% involving ransomware ^[7]. The University of Vermont Medical Center ransomware attack serves as a cautionary tale. It disrupted operations for weeks, affecting both electronic health records and medical imaging systems - a situation that impacted both safety and data security ^[7].

Here’s how FDA and HIPAA handle cyber incidents differently:

The key takeaway? Technical controls often address both frameworks simultaneously. For example, encryption meets the requirements of both FDA and HIPAA. Organizations that integrate compliance efforts, treating FDA and HIPAA as complementary rather than separate, are better equipped to manage incidents efficiently.

"Ensuring medical device safety and effectiveness includes adequate medical device cybersecurity, as well as its security as part of the larger system." - FDA ^[5]

sbb-itb-535baee

Cybersecurity and Software Lifecycle Regulations

FDA Cybersecurity Guidance for IoT Devices

The FDA's approach to cybersecurity goes far beyond the initial premarket submission. Under Section 524B of the FD&C Act, manufacturers are required to view cybersecurity as an ongoing obligation. A "cyber device" is defined as one that includes sponsor-authorized software, has internet connectivity, and possesses characteristics that make it vulnerable to cybersecurity threats ^[4].

Section 524B outlines three key responsibilities for manufacturers:

Manufacturers must address known vulnerabilities regularly and resolve critical issues immediately ^[4]. In June 2025, the FDA updated its guidance on cybersecurity documentation for medical devices to clarify these expectations further ^[8].

"The landscape now is to design controls in, period. The FDA's cybersecurity authority is no longer based solely on risk assessments. It's based on statute, and statute says you must prove secure by design." - Naomi Schwartz, VP of Regulatory Strategy, Medcrypt ^[12]

These regulations also align with broader international standards, which continue to refine cybersecurity practices.

International Cybersecurity Standards for IoT

To meet FDA requirements and ensure global compliance, manufacturers must also adhere to international frameworks. Several standards are particularly relevant to healthcare IoT:

• IEC 62304: This standard governs the software development lifecycle for medical devices. It categorizes software into three safety classes (A, B, or C) based on the potential harm it could cause. The higher the class, the more stringent the design, testing, and documentation requirements ^[3].
• ISO 14971: This standard provides a framework for managing risk. It works alongside software standards to identify vulnerabilities and assess the likelihood and severity of harm ^[3][10].
• ISO/IEEE 11073-40101:2022: This standard focuses on systematic vulnerability assessments using the STRIDE classification - Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege ^[10]. It offers a structured approach to threat modeling.
• ISO 81001-1:2021: Covering the entire lifecycle of health software and IT systems, this standard emphasizes safety, security, and effectiveness from concept to decommissioning. It's particularly relevant for devices integrated into hospital IT ecosystems ^[9].

In April 2026, Amotus completed firmware development for Zillia's connected ocular-diagnostic device, ensuring compliance with IEC 62304, ISO 14971, and FDA 524B post-market requirements ^[3].

"A 524B plan is only credible if you can actually push a governed, audited update to a deployed fleet - which is an architecture decision you make at the start, not a document you write at the end." - Christian Simard, VP Technology & Innovation, Amotus ^[3]

Secure Software Development and Device Updates

Ensuring cybersecurity throughout the software development lifecycle is essential for both compliance and safety. This process builds on established cybersecurity protocols and highlights the importance of continuous security measures.

One tool that simplifies this process is the Predetermined Change Control Plan (PCCP). This allows manufacturers to roll out certain updates to devices in the field without requiring a full premarket submission each time ^[11]. For companies managing extensive device fleets, this approach can significantly ease the operational workload of maintaining up-to-date firmware.

End-of-life planning is another critical but often overlooked aspect. Devices approved before March 29, 2023 are exempt from these regulations unless they undergo updates. However, if an update triggers a new premarket submission, the updated device must comply with the latest standards ^[2]. The FDA is also paying closer attention to whether older devices were designed with the best practices available at the time. If they pose ongoing risks to public health, the agency may push for their removal or replacement ^[12].

"Even if a device was never meant to connect to the internet but includes a wireless communication protocol, manufacturers must still account for potential threats." - Exponent ^[11]

Advancing Clinical IoT with IEEE/UL 2933: A Framework for Trust, Security, and Interoperability

International and Cross-Border Compliance for Healthcare IoT

When it comes to healthcare IoT, meeting U.S. regulations is just one piece of the puzzle. Manufacturers also need to navigate strict international and cross-border requirements.

EU MDR and GDPR for IoT Devices

Deploying IoT medical devices in Europe means complying with two major frameworks: EU MDR 2017/745 for device safety and GDPR for data privacy. Under the EU MDR, software intended for medical purposes is classified as a medical device - even if it’s cloud-based. Most cloud-based IoT software that supports clinical decisions falls under Class IIa according to Rule 11. However, apps focused solely on lifestyle or wellness are excluded.

One noteworthy difference from U.S. regulations is liability. Non-EU manufacturers are required to appoint an authorized EU representative who shares legal responsibility for any device defects. On the data side, GDPR mandates that health data generated by IoT devices stays within approved jurisdictions. This means cloud providers must sign data processing agreements, while manufacturers are responsible for ensuring compliance with regional data residency rules.

"The platform does not determine the regulatory pathway; the intended use does." - Ran Chen, Global MedTech Expert

Starting May 28, 2026, registration of Class IIa through Class III devices in the EUDAMED database became mandatory. This centralized system tracks device identities, certificates, and clinical data, while requiring manufacturers to maintain accurate software versioning for IoT products. This approach enforces strict traceability and adds another layer of complexity to cross-border compliance.

Moving Toward Global Standards Alignment

International frameworks are increasingly aligning with U.S. standards, making it easier to adopt consistent cybersecurity and lifecycle protocols. For instance, the U.S. QMSR now aligns with ISO 13485:2016, and SBOM (Software Bill of Materials) requirements are being adopted globally, thanks to laws like the EU Cyber Resilience Act and the NIS2 Directive.

The EU Cyber Resilience Act (CRA), passed in 2024, mirrors the U.S. Section 524B SBOM requirement. It mandates security updates for at least five years after a product’s launch and requires reporting security incidents within 24 hours. Meanwhile, the NIS2 Directive, effective October 2024, compels European healthcare providers to evaluate the healthcare supply chain security challenges of every IoT device they purchase.

Here’s a quick breakdown of key cross-border regulatory requirements:

These evolving standards are gradually reducing compliance barriers across regions. Tools like Censinet RiskOps™ help manufacturers manage risk assessments and stay on top of complex regulatory demands across multiple markets.

Compliance and Lifecycle Management for Healthcare IoT

Governance and Risk Management for IoT

In healthcare, IoT compliance spans the entire lifecycle of a device - from its initial design to its eventual decommissioning. Achieving this requires a well-defined governance structure where responsibilities are distributed across multiple teams, rather than being isolated within a single department.

"A siloed SPDF rarely delivers consistent, comprehensive impact." - Exponent ^[11]

An effective governance model brings together clinical engineering, IT security, regulatory affairs, quality assurance, and legal counsel within a unified risk management framework. This framework, mandated by the Quality Management System Regulation (QMSR) and aligned with ISO 13485:2016, elevates IoT risk management to a formal quality process rather than treating it as just an IT issue.

For healthcare delivery organizations (HDOs), managing risk also includes having multi-disciplinary incident response teams ready to act within strict reporting deadlines. For instance, under CIRCIA, cyber incidents must be reported to CISA within 72 hours, and ransomware payments require a report within just 24 hours ^[7].

Once governance is established, the focus shifts to maintaining detailed and audit-ready documentation.

Audit-Ready Documentation and Certifications

Being audit-ready means keeping documentation up-to-date at all times, eliminating the need for frantic, last-minute preparation.

"Documentation is the product." - Christian Simard, VP Technology & Innovation, Amotus ^[3]

Manufacturers should maintain several key records, including:

• A Design History File (DHF) and Device Master Record (DMR) aligned with ISO 13485:2016.
• A risk management file as required by ISO 14971.
• Software lifecycle records per IEC 62304, which classifies software into Safety Classes A, B, and C based on the potential harm to patients. These classifications determine the level of verification and documentation needed.

Additionally, machine-readable Software Bill of Materials (SBOMs) in formats like CycloneDX or SPDX are now mandatory under FDA Section 524B for cyber devices. Automating SBOM creation during the build process is highly recommended, as manual tracking often leads to errors and inefficiencies. The EU also requires UDI registration as part of traceability documentation.

Comprehensive documentation not only supports audits but also enables effective postmarket monitoring and vendor risk management.

Continuous Monitoring and Vendor Risk Management

After establishing governance and maintaining thorough documentation, continuous monitoring becomes critical to ensuring compliance throughout a device's lifecycle. FDA Section 524B requires manufacturers to implement a robust post-market surveillance plan. This includes a coordinated vulnerability disclosure process and active monitoring for new threats. With remote code execution attacks on medical devices skyrocketing by 437% in 2023 ^[1], passive monitoring is no longer a viable option.

In hospital settings, continuous monitoring often relies on Network Detection and Response (NDR) tools. These tools identify unusual device behaviors, such as unexpected outbound connections or abnormal data usage. By continuously comparing SBOM data against vulnerability databases like NVD and CVE, organizations can quickly identify and address new risks in deployed devices. Meanwhile, regulations like the EU NIS2 Directive and the Cyber Resilience Act are pushing HDOs to formally assess the cybersecurity of every IoT product they procure.

Platforms such as Censinet RiskOps™ simplify these ongoing assessments. They allow healthcare organizations to track medical device risks, evaluate vendor cybersecurity, and maintain the necessary documentation to demonstrate compliance - all within a single, collaborative system.

Conclusion

Key Takeaways for IoT Compliance

Healthcare IoT compliance has shifted from being a recommended practice to a set of binding requirements that cover every stage of a device's lifecycle. In the U.S., regulations like FDA Section 524B and the Quality Management System Regulation (QMSR), which take effect on February 2, 2026, have made cybersecurity and quality management mandatory. Globally, frameworks such as the EU MDR, GDPR, NIS2 Directive, and the Cyber Resilience Act are also setting stricter standards, with mandatory EUDAMED registration starting May 28, 2026.

A shared principle across these regulations is that device safety and cybersecurity are inseparable. As the FDA clearly states, "Ensuring device safety and effectiveness includes adequate device cybersecurity, as well as its security as part of the larger system." ^[5] A device that performs clinically but is vulnerable to cyber threats cannot be considered safe under these guidelines. This concept forms the backbone of compliance efforts across regulatory and operational areas.

For healthcare organizations, meeting compliance demands a balanced focus on three areas: device safety (guided by ISO 14971 and IEC 62304), data privacy (under HIPAA and GDPR), and cybersecurity (mandated by FDA Section 524B and the Cyber Resilience Act). Neglecting any one of these creates significant risks for both patients and the organization.

Given the complexity of managing diverse vendors, device types, and regulatory requirements, effective risk management tools are essential. Platforms like Censinet RiskOps™ simplify this process by allowing healthcare organizations to monitor medical device risks, evaluate vendor cybersecurity risks, and maintain audit-ready documentation - all in one system. This approach reduces the operational workload while ensuring compliance throughout the device lifecycle.

The growing frequency of cyberattacks underscores the dual risks of noncompliance: financial penalties and threats to patient safety. Treating IoT compliance as an ongoing discipline is critical to safeguarding both patients and the reputation of healthcare organizations.

FAQs

Is my connected product a medical device or just a wellness app?

A product qualifies as a medical device if its purpose is to diagnose, treat, or prevent disease. On the other hand, products designed purely to encourage a healthy lifestyle are generally categorized as wellness apps. To figure out the regulatory status of your product, you can use the FDA’s Digital Health Policy Navigator. For managing cybersecurity and risk requirements related to medical devices, Censinet RiskOps offers valuable support.

Who is responsible for HIPAA compliance when IoT vendors handle ePHI?

IoT vendors working with electronic Protected Health Information (ePHI) for healthcare providers, health plans, or clearinghouses fall under the category of business associates according to HIPAA. This classification means they are legally required to follow HIPAA regulations to protect sensitive patient data.

To meet these requirements, vendors must take two critical steps:

• Build secure devices: Ensuring that their IoT devices are designed with robust security measures to protect ePHI.
• Sign a Business Associate Agreement (BAA): This agreement formalizes their commitment to safeguarding patient information in partnership with the covered entity.

For added support, tools like Censinet RiskOps can simplify the process of evaluating third-party risks and fostering collaborative security practices. These solutions can be a game-changer for vendors aiming to maintain compliance while ensuring patient data remains secure.

What must a medical device SBOM include, and how often should it be updated?

A medical device Software Bill of Materials (SBOM) needs to include every software component involved. This covers software developed by the manufacturer, third-party tools, commercial off-the-shelf software, open-source software, and any upstream dependencies. Since the SBOM serves as a record of the software supply chain, it must be kept current throughout the device’s lifecycle to account for any updates or changes. Tools like Censinet RiskOps assist healthcare organizations in maintaining these updates while ensuring strong security and effective risk management for medical devices.

Related Blog Posts

• Ultimate Guide to IoT Certification for Healthcare
• NIST CSF vs IoT Device Risks in Healthcare
• EU MDR Guidance for IoT Device Risk Assessments
• How GDPR Impacts IoT Data in Healthcare