Medical Device Third-Party Cybersecurity Risk Management Guide
Manage third-party cybersecurity risk for connected medical devices using FDA Section 524B, QMSR and ISO 13485 controls, SBOMs, vendor assessments, and threat modeling.
Why Third-Party Vendor Cybersecurity Risk Is Now a Core Regulatory Requirement
Every connected medical device is only as secure as its weakest supplier. A pacemaker's firmware may be engineered to the highest security standards, but a vulnerable Bluetooth module from a third-party vendor, an unpatched operating system component, or a cloud service provider with weak access controls can compromise the entire device.
In 2026, this reality has become a regulatory mandate, not just a best practice. Three converging regulatory developments have made third-party vendor cybersecurity risk management an unavoidable obligation for medical device manufacturers:
FDA Section 524B (effective since March 2023) requires manufacturers of cyber devices to demonstrate that the device and related systems are cybersecure — including components, software, and services provided by third parties.
QMSR (effective February 2, 2026) incorporates ISO 13485 by reference, which includes purchasing controls (Clause 7.4) that apply to cybersecurity-critical suppliers.
FDA Cybersecurity Guidance (updated February/March 2026) explicitly expects manufacturers to integrate cybersecurity risk management into their quality system, including oversight of third-party software and services.
This guide explains the regulatory requirements, provides a practical framework for managing vendor cybersecurity risk, and maps the requirements to QMSR, ISO 13485, and the NIST Cybersecurity Framework.
The Regulatory Framework
FDA Section 524B: Cyber Device Requirements
Section 524B of the FD&C Act, enacted through the FDORA legislation in December 2022, establishes statutory cybersecurity requirements for "cyber devices" — defined as any device that includes software and has the ability to connect to the internet or any "validational means." This includes USB, Bluetooth, serial ports, NFC, and Wi-Fi connections, not just internet-connected devices.
Key requirements that implicate third-party vendors:
| Requirement | Section 524B Provision | Vendor Risk Implication |
|---|---|---|
| SBOM | 524B(b)(1): Submit a software bill of materials | Must include all third-party components with version, vulnerability status, and support windows |
| Vulnerability management | 524B(b)(2): Demonstrate processes for detecting, responding to, and mitigating vulnerabilities | Must extend to vulnerabilities in third-party components, not just proprietary code |
| Security by design | 524B(b)(3): Design, develop, and maintain processes to ensure device cybersecurity | Must include security requirements flowing down to suppliers of cybersecurity-critical components |
| Post-market updates | 524B(b)(4): Provide updates and patches to address vulnerabilities | Must coordinate with third-party vendors for timely patches, especially for SOUP components |
QMSR and ISO 13485 Purchasing Controls
The Quality Management System Regulation (QMSR), effective February 2, 2026, replaces the former Quality System Regulation (QSR) and incorporates ISO 13485:2016 by reference. This has direct implications for vendor cybersecurity oversight:
ISO 13485 Clause 7.4 — Purchasing: Requires manufacturers to establish documented procedures for purchasing, evaluating suppliers, and verifying purchased product conforms to requirements. Under QMSR, cybersecurity requirements must be included in purchasing specifications for cybersecurity-critical components and services.
ISO 13485 Clause 7.4.2 — Purchasing Information: Purchasing documents must describe the product to be purchased, including requirements for approval of product, procedures, processes, and equipment. For connected devices, this extends to security requirements for software components, cloud services, and communication modules.
ISO 13485 Clause 7.4.3 — Verification of Purchased Product: Manufacturers must inspect or verify that purchased products meet requirements. For software components, this includes verifying security properties through vulnerability scanning, penetration testing, and SBOM validation.
ISO 13485 Clause 7.1 — Risk Management: Risk management must address risks from purchased products and outsourced processes, including cybersecurity risks from third-party software.
FDA Cybersecurity Guidance (February/March 2026)
The FDA reissued its cybersecurity guidance in February 2026 (updated from June 2025) to align with QMSR. Key vendor-related expectations:
Secure Product Development Framework (SPDF): Manufacturers must implement a secure development lifecycle that covers the entire supply chain, including third-party components.
Threat modeling: Must include threats introduced through third-party components, cloud services, and communication interfaces.
SBOM in machine-readable format: SPDX or CycloneDX format, maintained throughout the product lifecycle, including all third-party and open-source components.
Security testing: Penetration testing, vulnerability scanning, and fuzz testing must cover the complete device system, not just proprietary code.
Post-market vulnerability management: Continuous monitoring for vulnerabilities in all device components, including third-party libraries, with defined timelines for triage and remediation.
EU Cyber Resilience Act and NIS2
For manufacturers marketing in the EU, additional regulations impose vendor cybersecurity obligations:
Cyber Resilience Act (CRA): Expected to begin applying requirements in late 2026, the CRA will require manufacturers of products with digital elements to ensure cybersecurity throughout the supply chain, including vulnerability handling and SBOM obligations for third-party components.
NIS2 Directive: Requires essential and important entities (including medical device manufacturers) to manage supply chain cybersecurity risks, including vendor security assessments and contractual security requirements.
A Practical Vendor Cybersecurity Risk Management Framework
Step 1: Vendor Inventory and Classification
Create a comprehensive inventory of all vendors that supply software, firmware, cloud services, communication modules, or any component with cybersecurity implications.
Classification tiers:
| Tier | Criteria | Examples | Assessment Frequency |
|---|---|---|---|
| Critical | Direct access to patient data, device control functions, or safety-critical software | Cloud platforms hosting device data, Bluetooth/Wi-Fi module suppliers, AI algorithm providers | Quarterly |
| High | Indirect access to device systems or data, or components with known vulnerability history | Operating system providers, database vendors, third-party libraries with network functionality | Semi-annually |
| Medium | Peripheral components with limited device interaction but potential attack surface | UI framework providers, analytics libraries, development tool vendors | Annually |
| Low | Components with no network connectivity or data access | Mechanical component suppliers (if no embedded software) | At onboarding, then as triggered |
Step 2: Vendor Risk Assessment
For each vendor, assess cybersecurity risk across these dimensions:
Security posture assessment:
| Dimension | What to Evaluate | Evidence to Request |
|---|---|---|
| Security certifications | ISO 27001, SOC 2 Type II, IEC 62443 | Certification documents, audit reports |
| Vulnerability management | Process for identifying, triaging, and patching vulnerabilities | Vulnerability disclosure policy, mean time to patch, CVE history |
| Secure development practices | SPDF, code review, static/dynamic analysis, penetration testing | SDLC documentation, test reports |
| Incident response | Process for detecting, containing, and communicating security incidents | IR plan, communication procedures, historical incident reports |
| Supply chain transparency | Visibility into their own suppliers and dependencies | Their SBOM practices, sub-tier vendor oversight |
| Business continuity | Ability to maintain service during security events | BCP/DR plans, uptime SLAs, data backup practices |
Step 3: Contractual Security Requirements
Flow down cybersecurity requirements into vendor contracts. Key clauses:
Security requirements specification: Define minimum security standards for supplied components, aligned with FDA guidance and ISO 13485 purchasing requirements.
Vulnerability disclosure and notification: Require vendors to notify you of vulnerabilities within defined timeframes (e.g., 24 hours for critical, 72 hours for high).
Patch and update obligations: Define timelines for security patches, including who is responsible for developing, testing, and deploying patches.
SBOM provision: Require vendors to provide and maintain SBOMs for all supplied software components in SPDX or CycloneDX format.
Audit rights: Reserve the right to audit vendor security practices, either directly or through third-party assessors.
Incident cooperation: Require cooperation during security incident investigation, including access to logs, forensics data, and remediation support.
Data protection: Specify requirements for handling patient data, encryption standards, and access controls.
Step 4: Continuous Monitoring
Vendor risk is not static. Security postures change, new vulnerabilities emerge, and business relationships evolve. Implement continuous monitoring:
| Activity | Frequency | Tools and Methods |
|---|---|---|
| Vulnerability monitoring | Continuous | CVE databases, NVD, vendor security advisories, automated scanning |
| SBOM validation | At each release + quarterly | CycloneDX/SPDX validation tools, dependency analysis |
| Vendor security posture | Per tier schedule | Security rating services (BitSight, SecurityScorecard), questionnaire updates |
| Threat intelligence | Continuous | Threat feeds focused on medical device supply chain, MITRE ATT&CK for medical devices |
| Incident tracking | As triggered | Vendor notification, CISA advisories, public breach reports |
Step 5: Integration with Quality Management System
Under QMSR, vendor cybersecurity management must be integrated into your QMS, not managed as a separate discipline:
Design controls (ISO 13485 Clause 7.3): Include cybersecurity requirements from third-party components in design inputs. Trace vendor security properties through design outputs, verification, and validation.
Risk management (ISO 13485 Clause 7.1): Include third-party cybersecurity risks in ISO 14971 risk analysis. Treat a vulnerable vendor component the same way you would treat any other hazard source.
Purchasing (ISO 13485 Clause 7.4): Document cybersecurity requirements in purchasing specifications. Evaluate and monitor vendors against these requirements.
CAPA (ISO 13485 Clause 8.5.2): When a vendor cybersecurity issue triggers a complaint, deviation, or recall, process it through your CAPA system, not a separate IT security workflow.
Management review (ISO 13485 Clause 5.6): Include vendor cybersecurity risk status in management review inputs.
SBOM Management for Third-Party Components
The SBOM is the single most important tool for managing third-party cybersecurity risk. Under Section 524B, SBOMs are a legal requirement for cyber devices, not a recommendation.
SBOM Requirements for Vendor Components
| SBOM Element | What to Include for Third-Party Components |
|---|---|
| Component name | Exact name of the library, module, or package |
| Version | Specific version number |
| Supplier | Original vendor or open-source maintainer |
| Unique identifier | CPE, SWID, or PURL |
| Dependency relationships | Which of your components depend on this third-party component |
| License | Open-source license type (for compliance, not just security) |
| Support status | Whether the component version is still maintained/receiving security patches |
SBOM Workflow
At design: Collect SBOMs from all vendors during component selection. Reject components without adequate SBOM documentation.
At release: Generate a complete device SBOM aggregating all proprietary and third-party components. Validate against actual build artifacts.
Post-market: Monitor SBOM components continuously for new vulnerabilities. Track support windows — when a vendor stops supporting a component version, plan migration or mitigation.
At change: Update SBOMs for any software change, including vendor patches, version upgrades, and component replacements.
The MITRE Framework for Medical Device Cybersecurity Risk
In April 2026, MITRE published "Cybersecurity Risk Analysis for Medical Devices in the Era of Evolving Technologies," which explicitly addresses the challenge of managing risk when medical devices incorporate cloud computing, AI/ML, and post-quantum cryptography — often managed by third parties. Key takeaways for vendor risk management:
Shared responsibility model: Cybersecurity risk management of medical devices has always been shared between device manufacturers and healthcare delivery organizations. Now, additional third parties (cloud providers, AI service vendors, data analytics platforms) must be accounted for when defining roles and responsibilities.
Nth-party risk: Risks introduced by your vendors' vendors. A cloud service provider may itself depend on infrastructure providers, CDN operators, and other sub-contractors whose security posture directly affects your device.
AI/ML component risks: When AI/ML components are supplied by third parties, unique risks arise including adversarial manipulation of training data, model poisoning, and supply chain attacks on model weights.
Common Gaps and How to Address Them
| Gap | Risk | Solution |
|---|---|---|
| No vendor cybersecurity assessments | Blind spots in supply chain security | Implement tiered assessment program aligned with ISO 13485 Clause 7.4 |
| Incomplete SBOMs | Cannot identify vulnerable components when CVEs are announced | Require SBOMs from all software vendors; validate with automated tools |
| No contractual security clauses | Cannot enforce vendor cooperation during incidents | Add cybersecurity clauses to all agreements with cybersecurity-critical vendors |
| Siloed security and quality teams | Vendor cyber risks not managed through QMS | Integrate vendor cybersecurity into QMS risk management, design controls, and CAPA |
| No continuous monitoring | Vendor security posture changes undetected | Implement automated monitoring using threat intelligence and security rating services |
| Ignoring legacy devices | Older devices with unpatched vendor components remain in clinical use for years | Assess legacy device third-party component risks per IEC 81001-5-1; develop compensating controls and remediation plans |
The Legacy Device Challenge
One of the most significant vendor cybersecurity challenges involves legacy medical devices that were not designed with modern cybersecurity protections. These devices often remain in clinical service for 10–15 years, running software components whose vendors no longer provide security patches. The FDA's 2026 cybersecurity guidance acknowledges this reality, but manufacturers must still address it:
Inventory all third-party components in legacy devices, including those with expired support windows
Assess compensating controls — network segmentation, monitoring, and access restrictions that reduce risk when patching is not possible
Plan lifecycle transitions — document when legacy components will be replaced and how risks are managed in the interim
Communicate transparently with healthcare delivery organizations about known vulnerabilities and available mitigations
Healthcare Sector Breach Context
The urgency of vendor cybersecurity management is underscored by healthcare sector breach statistics:
96% of healthcare organizations experienced at least two data loss or exfiltration incidents over the past 24 months (Ponemon/Proofpoint 2025)
Average cost per healthcare data breach: $9.8 million (IBM/Ponemon Cost of a Data Breach Report 2024)
The Change Healthcare breach (2024) affected over 192 million individuals and disrupted operations across the entire U.S. healthcare system for months
Remote code execution and privilege escalation exploits in medical devices surged 437% in 2023
These figures demonstrate that vendor cybersecurity failures are not theoretical — they are frequent, costly, and directly affect patient care.
FAQ
What is third-party vendor cybersecurity risk management for medical devices? It is the process of identifying, assessing, and mitigating cybersecurity risks introduced by external suppliers that provide software, firmware, cloud services, or connected components used in medical devices. Under FDA Section 524B and QMSR, manufacturers are responsible for managing these risks as part of their quality system.
Does FDA Section 524B require vendor cybersecurity oversight? Yes. Section 524B requires manufacturers of cyber devices to submit SBOMs, implement vulnerability management processes, and ensure device cybersecurity — all of which require oversight of third-party components and services.
How does QMSR affect vendor cybersecurity management? QMSR incorporates ISO 13485, which requires documented purchasing controls (Clause 7.4), supplier evaluation, verification of purchased product, and risk management (Clause 7.1). Cybersecurity requirements must now be included in purchasing specifications and supplier assessments for cybersecurity-critical components.
What should be in a vendor cybersecurity contract? Key clauses include security requirements specification, vulnerability disclosure notification timelines, patch and update obligations, SBOM provision requirements, audit rights, incident cooperation, and data protection requirements.
What is an SBOM and why does it matter for vendor management? A Software Bill of Materials (SBOM) is a comprehensive list of all software components in a device, including third-party libraries and their versions. Under Section 524B, SBOMs must be maintained in machine-readable format (SPDX or CycloneDX) and enable rapid identification of vulnerable components when CVEs are announced.
How often should vendors be assessed for cybersecurity risk? Assessment frequency should be risk-based: critical vendors quarterly, high-risk vendors semi-annually, medium-risk vendors annually, and low-risk vendors at onboarding. Reassessment should also be triggered by vendor breaches, material changes in services, or new regulatory requirements.