Before connecting a medical device, I check whether its labeling supports safe use, maintenance, and incident response - not just whether documents exist. I match the records to the exact device and software versions, then require controls, assigned owners, and deadlines for medical device security risks.
My checklist covers 5 review areas:
- Device details and labeling: Confirm versions, deployment instructions, and which legal requirements apply.
- Connections and security controls: Review dependencies, accounts, remote access, encryption, logs, and physical access.
- Updates and vulnerabilities: Check patch delivery, clinical testing, recovery options, and manufacturer notices.
- Reporting and support: Verify security-reporting channels, response commitments, and after-hours contacts.
- Approval and reassessment: Record the decision, required safeguards, risk owners, and review triggers.
My rule is simple: <u>put required safeguards in place before deployment</u>. FDA guidance generally provides nonbinding recommendations; applicable laws and regulations still apply. I use this checklist - and Censinet RiskOps for tracking - to support HDO decisions, not replace manufacturer instructions, device testing, or legal advice.
HDO Medical Device Cybersecurity Review Checklist
Cybersecurity Labeling and MedTech Transparency | Ep. 25
sbb-itb-535baee
2. Review Architecture, Access Controls, and Encryption
Separate device capabilities from HDO-provided controls. Mark each item present, missing, unclear, or needing vendor clarification. A documented feature also needs configuration instructions before it can support approval. Base this technical check on the verified device model, software version, and label revision from the prior review.
Map Connections, Dependencies, and Remaining Risks
Request an architecture and data-flow diagram that covers interfaces, protocols, ports, services, operating systems, browsers, mobile applications, cloud services, and third-party integrations. It must show connected assets, trust boundaries, protected interfaces, authentication points, data types, and deployment prerequisites.[1][6]
Identify any segmentation or other HDO controls needed before deployment. Confirm which connections the device requires and what happens when a dependency becomes unavailable. Record limitations, residual risks, and HDO compensating controls.
Check SBOM availability, version coverage, machine-readable format, delivery method, revision process, support status, and end-of-support dates.[6][5] Escalate gaps that prevent the team from assessing attack paths, clinical interruption, or required compensating controls.
Check Accounts and Remote Access
Verify unique user identification, role-based access, least privilege, and account creation and removal. Review administrative, service, default, and emergency accounts. Request password, MFA, timeout, and lockout settings, and check whether they preserve emergency clinical access.[7]
For every remote-access method, require instructions for HDO approval, authentication, time limits, monitoring, and disablement after maintenance. HHS guidance recommends encrypted VPNs and MFA for remote access to OT and IoMT.[9]
Approve missing controls only with documented compensating measures, a clinical impact analysis, and an assigned HDO owner. Treat every unmet control as an input to the approval decision - not a standalone note.
Verify Encryption, Logging, and Physical Security
Request encryption specifications for data in transit and at rest. These should cover protocols, minimum versions, cipher suites, certificate validation, legacy exceptions, and responsibilities for key generation, storage, rotation, revocation, and recovery.
Encryption alone isn't enough. Verify which security-relevant events are logged, along with timestamps and time-zone handling, access permissions, retention, export methods, integrity protections, and monitoring responsibilities.[7][8]
Review physical access to consoles and service ports, boot restrictions, removable-media controls, and local maintenance ports or recovery modes. Identify every HDO safeguard required before connection.
Enter each finding in the review log for procurement and risk-review approval decisions. Include evidence status, device capability, required HDO control, unresolved vendor question, compensating control, residual risk, approval condition, owner, deadline, and reassessment trigger.
3. Review Updates and Vulnerability Management
Use the device model, software version, and label revision verified earlier to check how the manufacturer delivers fixes and tracks vulnerabilities.
For covered cyber devices, Section 524B requires postmarket monitoring, coordinated vulnerability disclosure, and timely remediation of known unacceptable vulnerabilities. FDA guidance also sets lifecycle monitoring expectations. Document which requirements apply - do not assume a fixed patch deadline.[1][11] Approve only when evidence for update delivery, validation, and rollback matches the exact deployed configuration.
Check Patch Delivery and Clinical Validation
Request written commitments covering routine security patches, emergency out-of-cycle updates, firmware changes, and major upgrades. Record supported versions, end-of-support dates, and expected fix timelines by severity.
Check how updates reach the device: automatically, manually, on-site, through a service engineer, or through a secured portal. Document prerequisites, including maintenance windows, administrator privileges, compatible hardware, network access, and updated companion software. Confirm the official update source, digital-signature or hash verification process, and safeguards against unauthorized or corrupted firmware. Escalate any undocumented or unsupported update path. Don’t accept “regularly updated” as evidence.
Require manufacturer validation evidence that the update preserves intended clinical performance, cybersecurity controls, interoperability, alarms, data integrity, and regulatory-approved functions. Testing must cover the HDO’s actual configuration, including interfaces to the electronic health record, central monitoring, identity systems, network segmentation, accessories, and vendor-managed components. Define local regression tests and acceptance criteria before deployment.
Confirm the options if installation fails: rollback, backup restoration, recovery images, or device replacement. Document recovery time objectives, escalation contacts, and a tested procedure for restoring clinical operations. If patching must wait, record temporary controls and a contingency plan.
Review Vulnerability Monitoring and Advisories
Request the device’s lifecycle-support policy as part of third-party vendor risk management, vulnerability-monitoring sources, testing cadence, and advisory archive. Check advisory channels, severity criteria, customer notice timelines, affected versions, clinical impact, mitigations, and patch status.
FDA’s 2025 premarket guidance also calls for considering CISA’s Known Exploited Vulnerabilities Catalog when identifying known vulnerabilities in the device and its components.[11] An advisory flags exposure; it does not confirm a validated fix. Verify that a validated fix exists before scheduling remediation.
Assign owners for notice intake, impact review, remediation, and closure. Keep published commitments separate from assumed schedules.
Allow deferred remediation only with a written risk assessment, compensating controls, an accountable owner, a target remediation date, and a review deadline. Complete the category record with patch status, advisory source, known vulnerabilities, remediation owner, remediation deadline, validation evidence, recovery capability, and next review date. Mark evidence verified, partially verified, not applicable, or exception, and retain the reason for every unresolved finding.
Use these disclosure channels and owner assignments to check reporting paths and after-hours support next.
4. Verify Reporting Paths and Support Contacts
Check Vulnerability Disclosure Procedures
After reviewing patch and advisory handling, check how the manufacturer receives and routes vulnerability reports. Request its vulnerability disclosure policy and security contact. Confirm that labeling or linked documents point to a monitored email, form, or portal - not a general corporate page. Check which products and versions the policy covers, who can submit reports, and who handles connected services or third-party vendor security risks.
Reporting instructions should ask for the device model, software or firmware version, affected configuration, reproduction steps, and clinical impact. Confirm that reporters have a secure channel for sensitive evidence and instructions for removing PHI from logs and screenshots.
Require clear steps for acknowledgment, triage, severity assessment, and escalation, including how reporters receive remediation updates. FDA recommends acknowledging initial reports within a specified time frame. CISA’s model policy specifies 3 business days when contact information is provided.[10][12] Withhold approval until you verify both the reporting route and the responsible contact.
Record Support and After-Hours Contacts
Next, verify who answers urgent operational calls after hours. Keep separate entries for technical support, urgent incidents, vulnerability reports, patch/advisory notices, and privacy or data-security incidents.
For each entry, record the responsible role; phone, email, or portal; ticket-submission method; service levels; operating hours; time zone; holiday coverage; and backup contact. Request named contacts and contractual service levels. A directory listing alone does not establish coverage.
Test critical routes before approval. Record the date, local time and time zone, ticket number, response time, responder role, and any failed handoffs. Confirm after-hours staffing, urgent response, and escalation paths to incident response, biomedical engineering, privacy, and clinical leadership. Keep PHI and exploit details out of the test request.
Keep manufacturer support separate from regulatory reporting. Healthcare providers may use MedWatch Form 3500 for voluntary medical-device reports.
Attach the disclosure policy, support matrix, service-level commitments, reporting instructions, and test results. Record the evidence status and last verification date. For each unresolved finding, document the reason, owner, correction deadline, and approval condition.
Recheck contacts during reassessment and after contract renewal, organizational changes, major software or firmware updates, or a reported incident.
5. Set Approval Conditions and Reassessment Steps
After the technical review, turn the findings into a formal approval decision and reassessment plan.
Record Findings and Approval Decisions
An intake record is not approval evidence. Base the approval decision on the earlier findings for labeling, architecture, access control, encryption, updates, disclosure, support, and security testing.
Use only these statuses: verified, partially verified, not provided, or not applicable. Verified documentation does not prove production performance. For each not applicable finding, provide a written rationale tied to the device’s actual design and deployment.
Transfer the earlier checklist findings into the final approval record below. Enter actual results - not assumed outcomes.
| Checklist item | Evidence reviewed | Status | Risk owner | Required action | Due date | Approval decision |
|---|---|---|---|---|---|---|
| Label accuracy and deployment controls | Current labeling, architecture, access control, encryption, and integration test records | Enter final status | Designated HDO security reviewer | Resolve mismatches; validate required controls | MM/DD/YYYY | Enter final disposition |
| Updates and clinical validation | Patch procedures, release notes, and validation results | Enter final status | Designated clinical engineering lead | Confirm safe installation and downtime requirements | MM/DD/YYYY | Enter final disposition |
| Reporting and support commitments | Verified reporting routes, support coverage, and contract terms | Enter final status | Designated procurement lead | Resolve gaps in enforceable commitments | MM/DD/YYYY | Enter final disposition |
Select one overall disposition:
- Meets requirements
- Meets requirements with compensating controls
- Needs manufacturer clarification before purchase or connection
- Needs contract, support, or documentation updates
- Not approved for deployment
For each unresolved risk, record the threat, affected patient-care function, impact rationale, required controls, accountable owner, deadline, and HDO acceptance authority. Put required safeguards in place before the deployment they protect.
Use the shared risk record to assign owners, track deadlines, and reopen the review when conditions change.
Track Reviews and Follow-Up in Censinet RiskOps
Use Censinet RiskOps™ to route evidence, assign remediation, and schedule reassessment. Designated HDO reviewers retain approval authority. Completing the workflow does not establish FDA compliance or replace device-specific technical and clinical validation.
Repeat the checklist during procurement, before production connection, after material configuration or software changes, at scheduled reassessments, and during incident-preparedness or downtime exercises. Newly disclosed vulnerabilities or failed controls should also trigger a review. Cybersecurity oversight continues throughout the device lifecycle.[1][2]
Capture the final review record for procurement and follow-up. Include the device, manufacturer, model, software/firmware and labeling versions, intended use, location, scope, evidence links, and checklist results. Also record unresolved risks, controls, owners, deadlines, disposition, reviewers, approving authority, review date, and next reassessment date.
Note whether testing used a representative environment, and list any deployment restrictions.
FAQs
How do I assess a legacy device with incomplete labeling?
First, check whether the device can be patched or has reached its end-of-support date [1][2]. If it can’t be patched, flag it as an open risk and require vendor-documented compensating controls, such as network segmentation [3][2]. Name an owner, set a review timeline tied to milestones, and check the status monthly until the risk is addressed [3].
Censinet RiskOps™ can keep documentation in one place and automate risk assessments to simplify this process [1][4].
How do I know compensating controls are sufficient?
Document the temporary controls, which devices or units they cover, the residual risk, and the target date for a permanent fix. For each mitigation step, record the decision and its timing.
Keep devices that can’t be patched flagged as open risks. Assign each risk a named owner, set milestone-based timelines, and review its status at least monthly until it’s closed [1].
What if a critical patch disrupts patient care?
Put patient safety first: involve clinical engineering and the affected department immediately. Always test patches in a controlled environment before deployment. If you can’t apply a patch safely, use network segmentation, tighter monitoring, or manual clinical workflows. Your patch plan should also include validated emergency rollback steps.
Censinet RiskOps™ helps HDOs simplify risk assessments and manage risk together, supporting operational security and patient safety throughout the device lifecycle.
