I start every third-party component audit with one question: Can we verify that the supplied component is safe for its role in the device? That means checking the released version, tracing its source, testing supplier controls, and tracking problems through verified closure - not just collecting questionnaires.
My audit checklist covers four areas:
- Scope and ownership: Include hardware, software, firmware, cloud services, and dependencies. Set audit depth by patient risk and assign manufacturer, supplier, and healthcare delivery organization responsibilities.
- Records and testing: Match SBOMs to released builds, check component integrity, and assess how vulnerabilities could affect patient care.
- Findings and follow-up: Assign owners and deadlines, test corrections, and document any remaining risk before closing findings.
- Lifecycle checks: Reassess after updates, active exploitation, supplier failures, or end-of-support notices.
I also separate legal duties from FDA recommendations. Section 524B sets cybersecurity duties for applicable cyber devices, and the QMSR took effect on February 2, 2026. Automated assessment tools can help organize the work, but <u>they do not replace testing or the manufacturer’s regulatory accountability</u>.
FDA cybersecurity requirements: What is surprising and new in 2026?
sbb-itb-535baee
Supplier Review and Component Records
With ownership defined, audit the evidence showing that the controls work. Assign a documented supplier risk tier based on clinical criticality, connectivity, sensitive-data access, replacement difficulty, supplier concentration, and failure impact. Use that tier to decide which records need independent verification.[11]
Supplier Security Controls and Contract Terms
Review evidence of how the supplier works - not just its summary claims. Confirm that quality certificates, security policies, access controls, staff training, secure-development records, testing, and release controls cover the actual product, facility, and development team.
Validate incident response, recovery testing, continuity plans, and subsupplier oversight using controls validation and corrective-action records rather than high-level summaries. Contracts should spell out evidence access, audit rights, notification windows, material-change approval, remediation, and support commitments. These terms govern how the parties work together; they aren't universal FDA clauses.[6][10]
SBOM Accuracy and Component Integrity
Reconcile the current, machine-readable SBOM with architecture diagrams, dependency lockfiles, build records, and released binaries. Investigate missing embedded libraries, transitive dependencies, and firmware modules.
Link each component’s identity and version to vulnerability information, licenses, and end-of-support dates. If the SBOM format can't hold those details, use an auditable addendum. Record approved exceptions, and don't mark records complete while components remain unidentified.[6][9]
Keep linked but separate records for software and hardware. Software records should cover builds, dependencies, signatures, and updates. Hardware records should cover the manufacturer, part number, lot or serial number, supply-chain path, checks that confirm the component is genuine, and firmware configuration.
Keep acceptance-test requirements, expected and actual results, anomalies, and approvals separate from change records. Change records should document impact assessments, regression testing, and implementation dates. Investigate integrity mismatches before acceptance. Use controlled access to protect confidential records without withholding information needed for risk decisions.
Vulnerability Review and Patient-Care Risks
Use supplier advisories, NVD records, and CISA’s Known Exploited Vulnerabilities Catalog together. Supplier notices can be incomplete, NVD mappings can lag, and absence from KEV doesn't prove safety.
For each finding, document affected versions, reachability, exploit prerequisites, potential effects on therapy or alarms, tested safeguards, remediation options, residual risk, owner, and due date. CVSS alone is not an acceptance decision. Assess technical severity and patient-care impact separately.[2][6]
| Review area | Source and scope | Status |
|---|---|---|
| SBOM format and detail | FDA guidance and NTIA baseline elements; machine-readable identification and dependency information | FDA recommendation or submission expectation; distinguish from statutory coverage.[6][9] |
| Support status | Supplier maintenance commitments and end-of-support dates | FDA-recommended documentation and audit evidence. |
| Vulnerability assessment | Supplier advisories, NVD, KEV, and testing; device and connected-system impact | FDA cybersecurity risk-management expectation and supplier audit practice.[2][6] |
| Risk controls | Device risk files and validation evidence; mitigations and residual risk | FDA-recommended documentation and risk-based audit evidence. |
| Postmarket monitoring | Advisories, incidents, field data, and change notices; continued detection and response | Section 524B duties for applicable cyber devices, supplemented by FDA lifecycle recommendations and manufacturer-defined procedures.[6][8][12] |
Audit Steps, Findings, and Closure
Medical Device Component Audit: 8 Phases
Turn the supplier records you've reviewed into a structured audit plan.
Phase 1 - Plan the audit. Define the scope: device models, software and firmware versions, component suppliers, supplier risk tier, production sites, interfaces, cloud dependencies, support periods, and patient-care functions. Set audit dates, evidence owners, confidentiality requirements, approved testing environments, clinical-service safeguards, and escalation contacts. Assign auditors who are independent of the work under review.[14][15]
Audit Records and Validation Methods
Phase 2 - Request and index records. Use an audit checklist to confirm that released components match their documented evidence. Request inventory and configuration records, SBOMs, and records covering secure development, vulnerability management, testing, patching, incidents, supplier oversight, and prior audit/CAPA history.
Link SBOM evidence to released builds. Each record should identify its source, responsible person or system, affected release, and related audit question. Keep records attributable, versioned, tamper-evident, and retrievable for the device life or required retention period.[8][13][14]
Phase 3 - Interview personnel. Speak with supplier, engineering, quality, security, and service personnel. Review actual tickets and release decisions - not just questionnaire answers.
| Method | Primary purpose | Supporting records | Main limitations | Appropriate use |
|---|---|---|---|---|
| Document review | Check whether required controls are defined and supported by evidence | Procedures, SBOMs, contracts, test reports, CAPA records, audit trails | Documents may be outdated, incomplete, or disconnected from the released product | Establish baseline compliance and identify evidence gaps |
| Interviews | Check whether personnel understand and follow the documented process | Interview notes, role descriptions, training records, workflow examples | Responses may be subjective or differ from actual practice | Clarify ownership, exceptions, informal workarounds, and escalation paths |
| Technical validation | Confirm that the component, control, or release behaves as described | Hashes, build records, scan results, configuration exports, test logs, signed artifacts | Intrusive testing can disrupt clinical systems or produce results that do not reflect actual use | Verify versions, security controls, dependencies, patch status, and acceptance criteria |
| Continuous monitoring | Detect changes, new vulnerabilities, support expirations, and emerging exposure | Vulnerability feeds, SBOM-diff reports, asset telemetry, supplier notices, incident alerts | Monitoring can miss process failures, undocumented components, and weak governance; it does not replace an audit | Trigger reassessment, targeted testing, or corrective action between formal audits |
Phase 4 - Cross-check evidence against records. Compare supplier answers with dated records, build outputs, and test logs. Use the validated evidence to guide sampling of versions actually released.
Phase 5 - Sample released configurations. Choose samples based on clinical criticality, exposure, supplier risk, and change history. For each sample, reconcile the device model and approved release identifier with the build manifest, SBOM, signed artifact, test report, release approval, and production image. Check that the evidence is dated and attributable, names the exact version tested, and identifies who approved the release.
Set acceptance criteria before testing. Required controls must pass, and patches must preserve essential performance. Unresolved material SBOM omissions or known exploited vulnerabilities must fail acceptance or trigger escalation.
Limit intrusive testing to approved, isolated environments. Establish backups, rollback steps, stop conditions, and emergency contacts. Prohibit uncontrolled production scanning or live configuration changes.[2][8]
Finding Severity, Corrective Actions, and Closure
Phase 6 - Classify findings. Rate findings as critical, major, moderate, or minor based on patient-safety impact, exploitability, exposure, urgency, and regulatory relevance - not technical severity alone. Record the rationale and affected releases.
Phase 7 - Assign corrective action. Require an accountable owner, root cause, interim safeguards, permanent action, milestones, deadline, verification evidence, and escalation route. Separate the immediate fix from the steps needed to prevent recurrence. Escalate overdue high-risk actions to quality, security, clinical engineering, and regulatory leadership as appropriate.
Phase 8 - Verify effectiveness and close or escalate. A supplier promise or procedure update alone is not enough to close a finding. Independently retest the correction, sample later releases, or verify that the revised process detects discrepancies. Record the reviewer, date, evidence, result, and authorized approval. Reopen actions that prove ineffective.[14][15]
Any residual-risk acceptance must identify affected versions, safeguards, monitoring, an expiration date, reassessment triggers, and an accountable approving authority. Risk acceptance cannot waive legal, reporting, contractual, or quality-system obligations.[2][8]
Carry unresolved findings, reassessment dates, and monitoring triggers into lifecycle surveillance.
Lifecycle Monitoring and Common Audit Failures
Supplier approval is not final clearance. Even an unchanged component can become unsafe if its dependencies, threat exposure, support status, or clinical use changes. Use the surveillance triggers below to reopen findings, retest changes, or update risk acceptance. Monitoring should drive reassessment, maintenance planning, and continuity-of-care actions.[1][12]
Reassessment Triggers and Risk Metrics
Reassess after component updates, supplier acquisitions, newly discovered dependencies, active exploitation, repeated supplier failures, and end-of-support notices. Compare every updated SBOM with its approved baseline, and link changes to the affected releases and clinical workflows. Keep the comparison and document the required action: reopen findings for repeated failures, retest updates or new dependencies, notify affected customers when warranted, replace unsupported components, or record justified risk acceptance.[2][8][12]
Track the share of deployed devices with current SBOMs, time from disclosure to triage, aging findings, overdue actions, unsupported components, and repeat failures. Give each measure an owner and an escalation threshold so repeat problems and missed deadlines prompt action.[2][12][16]
Active exploitation of a safety-relevant component calls for immediate escalation to clinical safety teams and leadership. An unsupported connected component calls for a documented risk review. FDA does not set one universal remediation deadline. Set due dates based on risk, and plan spare inventory, migration dates, and clinical fallback procedures before support ends.[2][12][16]
Common Audit Failures and How to Fix Them
Use repeat findings to improve the next review - not just reopen the same issue. Tie corrections and records to every affected device version still in service.[8][12][16][17]
| Audit failure | Correction and verification record |
|---|---|
| Questionnaire-only reviews | Check attestations through sampled records, interviews, and technical checks. Keep the evidence-review results. |
| Incomplete SBOMs or missing dependencies | Reconcile dependencies against build manifests. Keep the discrepancy report and corrected SBOM. |
| Unverified deployed versions | Reconcile firmware, configuration, serial-number, and deployment records. Keep the verified inventory. |
| Weak patient-risk analysis | Assess therapy interruption, diagnostic integrity, recovery time, and fallback procedures. Keep the device-specific risk decision. |
| Contract gaps or overlooked subsuppliers | Require vulnerability notification, SBOM delivery, incident cooperation, patch timelines, subsupplier disclosure, and end-of-life notice. Keep signed terms and dependency records. |
| Single-source dependence | Map shared components across device families. Keep tested continuity plans and replacement feasibility assessments. |
| No scheduled or event-triggered reassessments | Set up scheduled and event-triggered reassessments. Keep the review history and resulting decisions. |
| Untested corrective actions or ownerless findings | Require accountable owners, deadlines, escalation criteria, and effectiveness checks. Keep test results and closure approval. |
Coordinating Supplier Risk With Censinet
Use Censinet RiskOps™ to organize evidence and follow-up across shared assessment workflows. Censinet helps healthcare delivery organizations and vendors with Censinet RiskOps™, which supports third-party assessments, evidence collection, remediation, cybersecurity benchmarking, and risk management. Shared assessment history lets teams track supplier commitments and route unresolved issues to the people responsible.[2][8][12]
The platform does not replace component testing, quality system duties, regulatory judgment, or human review of safety-critical decisions. It is not FDA compliance certification.[2][8][12]
Conclusion: Audit Program Priorities
With lifecycle triggers defined, plan the next audit cycle around patient risk. Rank audits by critical medical device security risks like patient-safety impact, cybersecurity exposure, connectivity, failure detectability, and compensating controls.
Keep statutory requirements separate from FDA guidance. For FDA-defined cyber devices, Section 524B requires cybersecurity processes, postmarket monitoring and response, software updates and patches, and an SBOM covering commercial, open-source, and off-the-shelf components.[2][4][7] FDA guidance provides implementation details, including machine-readable SBOMs and baseline data fields.[2][6][1]
Use one checklist and assign clear ownership for qualification, provenance, released-version evidence, and acceptance.
Track findings through verified closure. Each finding needs an identifier, affected device and component versions, clinical and cybersecurity impact, an owner, a due date, an evidence requirement, and residual-risk acceptance. Close findings only after objective verification, independent review, and documented approval. Carry open findings into scheduled reviews and lifecycle triggers.
FAQs
How do I determine whether Section 524B applies to my device?
Under Section 524B of the FD&C Act, a cyber device must meet all three criteria: it includes software validated, installed, or authorized by the sponsor; it can connect to the internet or another network; and it has technological features that could be vulnerable to cybersecurity threats. These criteria apply even if the device isn’t currently network-enabled.
If you’re unsure whether your device meets these criteria, the FDA recommends contacting the agency for clarification.
What if a supplier refuses to share audit evidence?
Treat refusal as a serious risk to procurement and renewal. Manufacturers remain responsible for inherited risks and device security. Record any missing evidence, provide the justification required by the FDA, and put compensating controls in place. These may include binary analysis, penetration testing, or network segmentation to isolate the component.
If support isn’t available, document a backup plan to replace the component or formally justify accepting the remaining risk to maintain FDA compliance.
When should I replace a component instead of accepting its risk?
Replace a component when it reaches end-of-life or its supplier can no longer provide patches [1]. You’re still responsible for inherited risks. If you can’t replace it right away, apply strict compensating controls, such as network segmentation [2][3][1][4].
If you choose to accept the risk, document a formal risk assessment, explain why an update isn’t possible, and keep records of hazard-mitigation controls for the FDA [2][3][5].
