The FDA's 2026 cybersecurity updates mark a major shift from voluntary guidelines to mandatory requirements for connected medical devices. Here's what you need to know:
- Mandatory Compliance: Cybersecurity is now integrated into the Quality Management System (QMS), requiring manufacturers to follow a Secure Product Development Framework (SPDF).
- Lifecycle Accountability: Manufacturers must monitor vulnerabilities, provide Software Bills of Materials (SBOMs), and issue timely patches for device security.
- Premarket Requirements: Submissions must include detailed risk management, security testing evidence, threat modeling, and SBOMs.
- Postmarket Plans: Ongoing updates, vulnerability disclosure, and patching are required throughout the device lifecycle.
- Impact on Healthcare: Hospitals must manage third-party risk, track SBOMs, utilize automated vendor solutions, and prioritize cybersecurity in procurement and operations.
These changes aim to ensure medical devices are secure by design, protecting patient safety and data integrity. Non-compliance could result in regulatory penalties or operational disruptions.
The New FDA Inspection Reality: The Shift from QSIT to QMSR & Section 524B Cybersecurity Audits
sbb-itb-535baee
Key Changes in the 2026 FDA Cybersecurity Guidance
The February 2, 2026, FDA guidance introduces a pivotal shift by embedding cybersecurity directly into the Quality Management System under the Quality Management System Regulation (QMSR). This update refines earlier recommendations and moves toward enforceable measures.
As George Strom, Director at Intertek Connected World, succinctly stated:
"Cybersecurity is not separate from quality - it is part of it."
From Recommendations to Mandatory Requirements
Previously, manufacturers had more leeway with FDA guidance, which leaned heavily on recommendations. That flexibility is now a thing of the past. Under Section 524B of the FD&C Act, cybersecurity requirements for connected devices are no longer optional - they are statutory. Non-compliance is now classified as a prohibited act under Section 301(q) of the FD&C Act [3].
The FDA is taking a stricter stance. Manufacturers that fail to adhere to secure-by-design protocols risk receiving deficiency letters. Similarly, eSTAR submissions with incomplete cybersecurity sections face Technical Screening holds [1].
Device Lifecycle Security and Risk Management
The updated guidance emphasizes a Secure Product Development Framework (SPDF), a structured process aimed at minimizing vulnerabilities from the design phase to decommissioning. Security is now a lifecycle-wide responsibility. Manufacturers are expected to integrate cybersecurity into every stage of the product's lifecycle.
To meet SPDF requirements, manufacturers can rely on recognized standards like IEC 81001-5-1 and the Medical Device and Health IT Joint Security Plan (JSP2). Additionally, all cybersecurity documentation must be traceable within the Design History File (DHF), a critical focus during FDA inspections. Risk management processes must align with ISO 14971 and AAMI TIR57, ensuring that safety and security risks are assessed together, not separately.
SBOM and Vulnerability Disclosure Requirements
For premarket submissions of connected devices, manufacturers must now include a Software Bill of Materials (SBOM). This SBOM must list all software components - commercial, open-source, off-the-shelf, and even upstream dependencies. Alongside this, a formal Coordinated Vulnerability Disclosure (CVD) plan is required, detailing how manufacturers will monitor, identify, and address vulnerabilities after the product hits the market.
It’s important to note that SBOMs aren’t static; they must be updated continuously throughout the product’s lifecycle. Phil Englert, Director of Medical Device Security at Health-ISAC, highlighted this shift:
"Vendors must provide a software bill of materials, manage the risks of those components, develop their product under a secure software development program and provide those SBOMs to customers upon demand." [4]
| Requirement | What's Expected | Legal/Standard Basis |
|---|---|---|
| Software Inventory | SBOM for all cyber devices | Section 524B(b) [6] |
| Development Process | Secure Product Development Framework (SPDF) | QMSR / ISO 13485 |
| Vulnerability Disclosure | Coordinated Vulnerability Disclosure (CVD) plan | Section 524B(b) [2] |
| Risk Management | Integrated security and safety risk analysis | ISO 14971 / AAMI TIR57 |
| Postmarket Updates | Patches and updates required throughout the lifecycle | Section 524B(b) [3] |
Premarket Submission Requirements for IoT Devices
Starting in 2026, the FDA's premarket review process for IoT devices emphasizes cybersecurity as a core component, going beyond just assessing safety. Manufacturers are now required to integrate cybersecurity into the design phase, with all related documentation managed under controlled Quality Management System (QMS) processes. This builds upon earlier FDA guidance to ensure a consistent approach throughout the product's lifecycle.
Security Risk Management Documentation
To meet the FDA's requirements, premarket submissions must seamlessly integrate risk management with cybersecurity validation. A key element of this is a documented Secure Product Development Framework (SPDF), which proves that cybersecurity was systematically addressed during the design and development phases. This documentation must be maintained within the Design History File (DHF).
Submissions should also include detailed security architecture views, covering aspects like global system design, multi-patient harm scenarios, updateability, and specific use cases. Threat modeling is another critical requirement and must align with ISO 13485 Subclause 7.3.3, directly linking to design inputs. Naomi Schwartz, VP of Regulatory Strategy at Medcrypt, highlights this shift:
"The rules of the game have changed. 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."
Additionally, critical medical device security risks must be evaluated alongside safety risks, using the ISO 14971 framework to ensure a comprehensive approach.
Software Validation and Security Testing Evidence
Once a strong security risk management framework is in place, manufacturers must validate and rigorously test their cybersecurity controls. ISO 13485 Clause 7.3.7 now mandates that design validation includes cybersecurity resilience.
The FDA expects manufacturers to adopt a multi-layered testing strategy, incorporating various methods to simulate and address potential threats. These tests include:
| Security Test | Role in Submission |
|---|---|
| Attack Surface Analysis | Identifies potential threat entry points |
| Fuzz Testing | Detects crashes or memory issues using randomized inputs |
| Vulnerability Scanning | Identifies known vulnerabilities in the closed-box product |
| Software Composition Analysis | Highlights risks in third-party and open-source components |
| Static/Dynamic Code Analysis | Finds hardcoded credentials and runtime flaws |
| Penetration Testing | Tests resilience against simulated real-world attacks |
All test results must be directly traceable to design verification and validation controls as outlined in ISO 13485 Subclauses 7.3.6 and 7.3.7. If the DHF doesn’t clearly document adherence to formal cybersecurity procedures during development, the submission risks receiving a deficiency letter.
Postmarket Update and Maintenance Plans
Cybersecurity efforts don’t end with premarket approval. Manufacturers are required to submit a postmarket cybersecurity management plan under Section 524B. This plan must address two update cycles: a regular cycle for addressing known vulnerabilities and an expedited cycle for critical vulnerabilities requiring immediate action.
A Coordinated Vulnerability Disclosure (CVD) procedure is also essential, providing a formal channel for external researchers and users to report security issues. George Strom, Director at Intertek Connected World, underscores the importance of this:
"A connected device that performs clinically but fails under cybersecurity stress is not meeting intended use expectations in today's regulatory environment."
Another critical tool is the Software Bill of Materials (SBOM). The SBOM helps identify devices affected by vulnerabilities in third-party components and determines the urgency for patches. However, treating SBOM generation as a one-time task instead of a controlled, ongoing QMS process is a common issue flagged by the FDA during reviews. Addressing this gap is crucial for maintaining compliance.
Preparing for FDA Cybersecurity Audits
The FDA's approach to cybersecurity audits is evolving, with new expectations tied to the updated Quality Management System Regulation (QMSR), effective February 2, 2026. These audits are no longer just about reviewing documentation - they now require cybersecurity to be fully woven into your Quality Management System (QMS). This shift emphasizes the integration of cybersecurity into every stage of your processes, rather than treating it as an afterthought.
How to Organize Cybersecurity Documentation
Under the QMSR, cybersecurity records must be part of your controlled QMS processes. They can’t simply stand alone as premarket deliverables anymore. As Ran Chen, a Global MedTech Expert, puts it:
"Cybersecurity documentation must now trace to controlled QMS processes, not be generated as standalone premarket deliverables." [7]
To meet these expectations, each cybersecurity record should map directly to specific ISO 13485 clauses. For example:
- Threat models should link to Design Inputs (Clause 7.3.3).
- Security architecture must connect to Design Outputs (Clause 7.3.4).
- Testing results should align with Design Verification and Validation (Clauses 7.3.6 and 7.3.7).
- Vulnerability monitoring should tie to Feedback (Clauses 8.2.1/8.2.2).
- Patch records must correspond with Corrective Actions (Clause 8.5.2).
FDA investigators will scrutinize your Design History File (DHF) for gaps where cybersecurity threats, controls, or test results aren’t clearly documented or linked.
Another key requirement is maintaining your Software Bill of Materials (SBOM) in machine-readable formats such as SPDX or CycloneDX. Additionally, your Coordinated Vulnerability Disclosure (CVD) plan must be more than just a written policy - it needs to be operational, with logs showing how reports are triaged and addressed.
Audit and management review records, previously less emphasized, are now firmly on the radar. Investigators will expect to see your internal audit findings and how management has responded to them.
This integrated approach ties directly into the Secure Product Development Framework (SPDF) and SBOM requirements, ensuring consistency between premarket submissions and audit processes.
IoT Cybersecurity Audit Checklist
To help you prepare, here’s a streamlined checklist of the 11 cybersecurity deliverables required for eSTAR submissions:
| eSTAR Deliverable | What Auditors Look For |
|---|---|
| Risk Management Report | Must integrate with safety risk management, avoiding silos. |
| Threat Model | Should provide a system-wide view (e.g., STRIDE or Attack Trees) and link to Design Inputs. |
| Cybersecurity Risk Assessment | Must use exploitability metrics like CVSS scores, not just probability-based scoring. |
| SBOM | A machine-readable inventory (e.g., SPDX, CycloneDX) of all software components. |
| Security Testing Reports | Evidence of penetration testing, fuzz testing, and vulnerability scans with traceability in the DHF. |
| Architecture Views | Should include global system views, multi-patient harm assessments, updatability, and specific security use cases. |
| Cybersecurity Labeling | Clear end-user guides covering configuration and update instructions. |
| Postmarket Management Plan | Active monitoring, defined patch timelines, and an operational CVD process. |
| Unresolved Anomalies | Assessment of known defects that could affect security. |
| Security Control Documentation | Details on authentication, authorization, cryptography, and data integrity controls. |
| Cybersecurity Metrics | Data demonstrating continuous monitoring of the device's security posture. |
In addition to these deliverables, auditors will also review your secure build pipeline. This includes documentation of Continuous Integration/Continuous Deployment (CI/CD) processes that automate security testing - such as fuzz testing and static/dynamic code analysis - on an ongoing basis, not just before submission. If you rely on third-party vendors for penetration testing, keep the original reports handy for audits.
Finally, don’t overlook your device labeling. Under Section 502(f) of the FD&C Act, insufficient cybersecurity instructions for end-users can result in a "misbranded" designation. This carries serious regulatory and legal consequences, so ensure your labeling meets the required standards. [6]
How the 2026 FDA Updates Affect Healthcare Organizations
FDA IoT Cybersecurity 2026: Vendor Tier Risk Management Framework
The 2026 FDA cybersecurity updates bring more than just changes for device manufacturers - they’re reshaping the way healthcare delivery organizations (HDOs) operate. From procurement and network architecture to clinical technology management, these updates ripple across nearly every department involved in connected care. For HDOs, this means rethinking not only how devices are onboarded but also how vendors and risks are managed over time.
Challenges in IoT Device Onboarding and Management
One of the first hurdles for HDOs is inventorying and certifying all connected devices. Medical devices and IoT/OT endpoints make up a large portion of hospital networks. Unlike standard workstations, these devices need specialized tools for identification, classification, and monitoring.
Legacy devices add another layer of difficulty. Many of these devices, still active in clinical use, were never built with modern cybersecurity in mind. Yet, they remain in service for years, sometimes decades. Now, replacement planning must prioritize cybersecurity risks alongside clinical functionality.
Procurement decisions are increasingly influenced by cybersecurity considerations. By 2026, 84% of healthcare organizations reported embedding cybersecurity requirements into their procurement processes, and 56% rejected medical devices due to security concerns - a jump from 46% in 2025 [9].
Third-Party Risk Management and Vendor Monitoring
As device onboarding becomes more complex, the need for thorough vendor risk assessments grow. Under the shared responsibility model outlined in FDA guidance, HDOs are responsible for secure configuration, network integration, and timely patching of devices once deployed [3][4]. This makes vendor relationships an ongoing operational priority.
Vendors are now required to provide machine-readable SBOMs (Software Bill of Materials) in formats like SPDX or CycloneDX. However, it’s up to HDOs to act on SBOM data by cross-referencing component inventories with vulnerability databases like NVD/CVE to address risks effectively [8].
Vendors are categorized into tiers based on their access to patient data or device control functions, with assessment schedules tailored to their risk level [10]:
| Vendor Tier | Criteria | Assessment Frequency |
|---|---|---|
| Critical | Direct access to patient data or device control (e.g., cloud platforms, AI providers) | Quarterly |
| High | Indirect system access or known vulnerability history | Semi-annually |
| Medium | Peripheral components with limited interaction | Annually |
| Low | No network connectivity or data access | At onboarding |
Contracts must also include requirements for vendors to notify HDOs of critical vulnerabilities within 24 hours and high-risk vulnerabilities within 72 hours. These agreements should clearly outline patching responsibilities and grant audit rights to ensure compliance [10].
How Risk Management Platforms Support Compliance
With so many moving parts - from device procurement to vendor oversight - HDOs are increasingly relying on integrated platforms to simplify compliance. Managing FDA cybersecurity requirements across a large fleet of devices while tracking vendor risks, SBOMs, and postmarket updates is too complex for manual workflows alone.
Censinet RiskOps™ offers a solution tailored for healthcare organizations. It supports third-party and enterprise risk assessments, cybersecurity benchmarking, and collaborative risk management for medical devices, clinical applications, PHI, and supply chains. For HDOs juggling dozens or even hundreds of vendor relationships, this platform centralizes the entire process. It replaces scattered spreadsheets and manual workflows with automated assessments and a unified risk management hub.
The platform’s Censinet AI™ feature speeds up the assessment process. Vendors can complete security questionnaires in seconds, and the system automatically summarizes evidence, documentation, and risk summary reports. This efficiency is critical as tighter patching cycles - potentially requiring 24-hour responses - become the norm to counter AI-driven threats [9]. Importantly, human oversight remains integral, with customizable review processes ensuring automation supports, rather than replaces, key decision-making.
Conclusion: Meeting FDA IoT Cybersecurity Requirements in 2026
The 2026 FDA updates make cybersecurity a mandatory requirement, embedded at every stage of a medical device's lifecycle. Naomi Schwartz, VP of Regulatory Strategy at Medcrypt, highlights this shift, noting that cybersecurity controls must now be built into devices by law. [5]
Key Takeaways for Manufacturers and HDOs
For device manufacturers, the transition to QMSR introduces a new reality: cybersecurity is no longer optional but must be part of the quality management system. Manufacturers are now required to include SBOMs, comply with SPDF guidelines, and submit comprehensive cybersecurity documentation in premarket filings. Even updates to legacy devices must meet the latest standards. [1][5]
For HDOs, operational priorities include network segmentation, passive device monitoring, and ensuring vendor contracts align with cybersecurity expectations. With medical devices accounting for 5% to 11% of hospital network endpoints [4], the potential attack surface continues to expand, making these strategies critical.
These insights outline actionable steps for both manufacturers and HDOs to address compliance challenges.
Next Steps for Compliance Readiness
To prepare for these changes, both manufacturers and HDOs need to act quickly.
For manufacturers, the focus should be on integrating cybersecurity documentation into the DHF, aligning efforts with ISO 13485 standards (Clauses 7.3 and 7.1). [2][5] Automated security testing - such as fuzz testing, static and dynamic code analysis, and penetration testing - should become a standard part of the development process. [6]
For HDOs, improving vendor oversight and managing device inventories are key priorities. Addressing issues like SBOM tracking and third-party risks can be streamlined with tools like Censinet RiskOps™. This platform simplifies risk assessments, automates vendor questionnaires, and centralizes SBOM management, replacing manual processes that often fail under the pressure of scale or time constraints. As George Strom, Director at Intertek Connected World, aptly stated:
"A connected device that performs clinically but fails under cybersecurity stress is not meeting intended use expectations in today's regulatory environment." [2]
FAQs
What devices do the 2026 FDA cybersecurity rules apply to?
The FDA's upcoming 2026 cybersecurity regulations apply to devices equipped with software, firmware, or programmable logic that pose cybersecurity risks. These are categorized as cyber devices under Section 524B of the FD&C Act. To qualify, such devices must meet the following criteria: include software validated or installed by the sponsor, have internet connectivity, and possess features that could be exploited by cyber threats. Connectivity options encompass Wi-Fi, cellular, Bluetooth, RF, USB, Ethernet, and other hardware connections - even in older, legacy devices.
What’s the fastest way to get SBOMs from vendors and keep them updated?
To streamline the process of obtaining and updating vendor SBOMs, rely on automated tools like APIs or secure Trust Centers instead of outdated manual email requests. It's also wise to include specific clauses in procurement contracts that require SBOMs to be provided in machine-readable formats, such as SPDX or CycloneDX. Since SBOMs change with firmware updates, they need to be updated regularly and shared without delays.
Platforms like Censinet RiskOps can make this process easier by automating assessments, centralizing risk data, and keeping track of vulnerabilities across vendor devices. This ensures you're always working with the latest information.
What evidence is needed for an FDA cybersecurity audit under QMSR?
To get ready for an FDA cybersecurity audit under QMSR, you'll need to demonstrate that cybersecurity has been thoughtfully incorporated into your product's design, development, and lifecycle processes. The evidence you provide should align with ISO 13485:2016 standards and include the following key elements:
- Security Risk Management Report: A document outlining how you've identified, assessed, and mitigated cybersecurity risks.
- Threat Model: A detailed analysis tailored to your product's architecture, showing potential vulnerabilities and attack vectors.
- Software Bill of Materials (SBOM): A comprehensive list of all software components, including third-party and open-source elements, to ensure transparency.
- Cybersecurity Testing Results: Evidence of robust testing, such as penetration testing, to validate the security measures in place.
- Cybersecurity Management Plan: A plan that outlines how you'll handle post-market activities, including monitoring, addressing unresolved vulnerabilities, and responding to emerging threats.
These components collectively demonstrate your commitment to maintaining cybersecurity throughout the product lifecycle.
