Auditing Third-Party Components in Medical Devices

If you build or maintain an FDA-regulated medical device, you need a clear record of every third-party component, its risk, its support status, and how updates are tested before release. That is the core point.

I’d boil the article down to this:

• Third-party code can make up 80%+ of a device codebase
• FDA Section 524B expects cybersecurity records, including an SBOM
• QMSR took effect on February 2, 2026, adding supplier control duties through ISO 13485 purchasing rules
• Risk should drive the audit, so high-impact components get checked more often
• Inventory alone is not enough - I also need supplier records, vulnerability review, patch testing, healthcare third-party risk management, CAPA tracking, and traceability
• Unsupported components are a direct problem and need either replacement plans or risk controls
• Update checks must happen in the actual device setup, not just in a supplier lab
• Findings need owners, due dates, and closure proof

A few numbers make the stakes clear. The article notes that exploits tied to remote code execution and privilege escalation in medical devices jumped 437% in 2023. These risks to patient care often stem from disruptions to clinical applications caused by such cyberattacks. It also points out that patch notice targets may be as short as 24 hours for critical issues and 72 hours for high-severity issues.

Here’s the simplest way I’d frame the process:

1. Set scope for software-enabled and connected devices, including older devices still in use
2. Build the component inventory with versions, hashes, dependency links, supplier names, and EOS dates
3. Match each component to device use and patient risk
4. Review supplier records like SBOMs, SQA terms, VEX statements, test reports, and service certificates
5. Check update controls like code signing, integrity checks, rollback, and patch timing
6. Test changes in the device setup for safety, performance, and interface effects
7. Log findings in CAPA with closure proof and residual risk records where needed

I see the article’s message as simple: an audit should prove that each outside component is known, supported, checked for risk, tested after change, and tied to quality records. If I can’t show that fast during an FDA inspection or internal review, the process is not ready.

Medical Device Cybersecurity: FDA Compliance & Threat Protection | DeviceTalks West 2024

sbb-itb-535baee

Define the audit scope and build the component inventory

Before you audit anything, you need a clear line around what counts. Under Section 524B, that scope starts with software-enabled devices that have external interfaces like USB, Bluetooth, Wi‑Fi, or NFC, and some level of cybersecurity exposure. ^[2][4] It should also cover legacy devices still being used in care, even when third-party support has already ended. ^[2]

Scope also needs a risk tier. If you treat every component the same, you burn time on low-impact items and miss what matters most. A practical way to sort this is to place components into four tiers based on what they connect to and how much harm a compromise could cause. ^[2]

Once the scope is set, build an inventory that links each component to device function, risk, and ownership.

Map each component to device function and risk

The inventory is your audit record. For each component, note where it is used in the device, whether it affects essential performance or safety-critical functions, what data it handles, and whether it touches PHI or shapes clinical workflows. ^[2] This mapping ties software parts to patient safety outcomes and supports risk analysis under ISO 14971.

The NTIA minimum elements for each SBOM entry include:

• Supplier name
• Component name
• Version string
• A unique identifier such as CPE, PURL, or SWID
• Dependency relationships

The FDA also expects SBOMs in standardized machine-readable formats like SPDX or CycloneDX so teams can support automated vulnerability monitoring. ^[2][3]

Record ownership, versions, and lifecycle status

Each inventory record should include the current version, release date, a component hash such as SHA-256 for integrity checks, support status, and end-of-support (EOS) date. ^[3] When vendor support ends, the risk does not disappear. It shifts to the manufacturer. That means migration plans or compensating controls, like network segmentation, should be in place well before the EOS date hits. ^[2][3]

Each record should also be cross-referenced to the device’s SBOM, Design History File (DHF), and risk analysis. Without traceability, it’s just a list. With traceability, it becomes audit evidence.

Use this inventory as the input for supplier evidence review and update validation.

Review supplier evidence and regulatory documentation

Use your inventory to request evidence for each component, starting with the highest-risk items. Every artifact should tie back to a specific component, version, and support status in your inventory records. At each step, keep one audit question front and center: "Does this evidence support the manufacturer's cybersecurity and quality duties for this exact component?"

Collect the required audit artifacts

Start by collecting the SBOM, SQA with vulnerability notification timelines, support status, and EOS date for each component. For suppliers that support safety- or security-critical functions, collect static analysis, dynamic analysis, and penetration test results too. Ask for a VEX statement so you can see whether a known CVE is exploitable in your device. If open-source support data isn't available, document the FDA-required justification and the compensating controls.^[2]

This is the point of the exercise: not just gathering files, but checking whether the supplier's controls line up with the device's actual risk.

Verify that supplier controls support manufacturer obligations

Collecting documents is only half the work. The other half is making sure those documents match what the supplier actually does.

Under the QMSR, effective February 2, 2026, cybersecurity requirements must be built into ISO 13485 purchasing controls. That includes purchasing specifications for cybersecurity-critical suppliers, and both internal and supplier audit records may be subject to FDA review.^[2]

When you review supplier contracts, look for clear notification timelines, such as 24 hours for critical issues, along with patch delivery commitments and an explicit right-to-audit clause. Check that the supplier's SBOM is validated against actual build artifacts at each release, not just generated once and filed away. For cloud and AI components, confirm there is a documented shared responsibility model that spells out which party owns data security, model validation, and incident response for the specific device context.

Compare evidence requirements by component type

Compare evidence by component type so you don't end up asking for the wrong documents.

These evidence priorities help you spot gaps fast. For software, focus on dependency transparency. For firmware, look closely at update controls and interface security. For cloud services, make sure the assurance documents are scoped to the supplied service. SOC 2 Type II only counts if the scope covers the product or service you use, so check the certificate scope itself, not just the fact that a certificate exists.

Assess security controls and validate updates in the device environment

Use the inventory and supplier evidence from the prior step to check how each update behaves inside the device itself. A third-party risk review is a start, not the finish line. You still need to confirm that the controls work in the actual device configuration.

Evaluate vulnerability management and secure update controls

Compare the supplier's monitoring cadence with the JSP recommendation: daily scans for critical components, weekly scans for all components, and monthly status reviews ^[1]. Then look at patch handling in practice. Measure average patch time, and confirm the supplier has met the notification timelines in your contract: 24 hours for critical issues and 72 hours for high-severity issues ^[2].

For update delivery, verify these controls in the device environment:

• Code signing
• SHA-256 integrity checks
• Authenticated update channels
• Tested rollback capability

On paper, these controls can look fine. In the device, they need to hold up under actual use.

Test component changes for safety, performance, and interoperability

Validate each patch in the deployed device configuration, not in isolation. Changes should also go through system-level security testing in that same configuration ^[2].

A code-path review helps answer a basic but important question: does the changed component touch a safety-critical function, or does it only affect a noncritical function such as data uploads? That distinction shapes the depth of testing.

Use the component record to identify:

• The exact version
• The dependency path
• The device function affected

Then map the change to the traceability matrix before choosing regression tests. Record the test result, the affected version, and the control owner. That way, if someone asks six months later, “Why was this patch approved?” you have a clean answer instead of a scramble.

Document acceptable and high-risk update practices

Use the table below to separate defensible change control from audit risk.

Every update should move through QMS change control with a change control record and an updated SBOM entry. If a supplier update slips in without documentation, that creates audit risk under 21 CFR 820.30(i) and configuration management.

Record findings, assign remediation, and maintain continuous oversight

Once you've checked the update, each finding should move into CAPA with a clear owner and proof of closure. For every finding, log the CVSS score, affected component, clinical impact, assigned owner, and any compensating controls already in place.

Under QMSR, third-party cybersecurity findings should go through CAPA under ISO 13485 Clause 8.5.2 - not into a general IT ticket queue. That split matters. Engineering should own the technical fix, while Quality or Regulatory should own updates to the risk record. It keeps roles clear and avoids the usual finger-pointing later.

Track findings, corrective actions, and closure evidence

The simplest way to keep this clean is to use one CAPA record per finding. Then assign ownership and closure proof based on severity.

If a vulnerability can't be patched yet, document the compensating controls and the residual-risk acceptance in the risk file. No shortcuts. If it's not written down, it may as well not exist.

Scale the process with centralized risk workflows

Manual tracking across devices and suppliers falls apart fast. Spreadsheets multiply, owners change, and evidence gets lost in email threads. Censinet RiskOps™ brings assessments, evidence, and remediation tracking into one place across the device lifecycle, which helps support continuous oversight of medical device cyber risk under FDA Section 524B and QMSR.

Conclusion: What a defensible component audit should deliver

A defensible audit should produce five things: a current, accurate inventory tied to device function and risk; supplier evidence showing controls are in place; a security and update review checked against the actual device configuration; documented remediation with traceable closure evidence; and a repeatable process that stands up across the device lifecycle.

When an FDA inspector or internal auditor asks for proof, those five pieces should be ready right away - not pieced together after the fact.

FAQs

How often should we audit third-party components?

Use a risk-based, tiered approach.

Audit critical vendors every quarter and high-risk vendors twice a year. Review medium-risk peripheral components once a year, and check low-risk components only during onboarding.

Also, keep the Software Bill of Materials up to date and monitor vulnerabilities continuously across the full device lifecycle.

What should we do about unsupported components?

Document this decision in your risk management files.

For each unsupported or abandoned component, spell out why it can't be updated, run a formal risk assessment, and record the compensating controls you’re using to cut the hazard.

You should also document how the component will be monitored without vendor patches. If the end-of-support date isn’t clear, check the project’s commit history or community activity to judge its status, then keep that record on file for the FDA.

Why must patch testing happen in the actual device environment?

Patch testing needs to happen in the actual device environment. Security testing has to look at the entire system, not just isolated parts.

That matters because third-party libraries and firmware don’t run on their own. They interact with proprietary code and device communication interfaces, and those connections can create problems you won’t spot in a lab test of a single component. Full-system testing helps confirm that patches don’t introduce new risks or failures.

It also helps verify security, validate mitigations, and support the configuration control needed to meet FDA expectations across the device’s 10- to 15-year lifespan.

Related Blog Posts

• Minimum Cybersecurity Standards for Medical Device Suppliers
• FDA Guidance: Securing Third-Party Libraries in Devices
• How Third-Party Software Impacts Patient Safety
• FDA Guidance: Managing Third-Party Components in Devices