How to update cybersecurity assessments and controls between scheduled reviews.
By Kaarthick Subramanian, chief information security officer and chief customer officer, Atlas Systems
A connected medical device could pass its scheduled maintenance check while its cybersecurity risk changes before the next review. A vulnerability could be found in a software component, a vendor could discontinue support, or a network change could increase exposure.
Even though the device continues to operate normally, its security assessment could be outdated. Healthcare technology management (HTM) teams need to connect those changes to devices in service and the people who will take action. Scheduled reviews act as a safety net; event-triggered reassessment can address changes that cannot wait.
Continuous compliance means maintaining up-to-date risk assessments, controls, and supporting documentation. The goal is to reduce the time between a significant change and a verified response. An accurate record helps support compliance when it reflects the device’s actual condition and the action taken.
An Advisory Can Alter the Clinical Workflow
The US Food and Drug Administration’s (FDA) January 2025 safety communication regarding Contec CMS8000 and relabeled Epsimed MN-120 patient monitors demonstrates how an external finding can necessitate reassessment of equipment currently in use. In July 2025, the FDA revised the communication to describe a software patch that, once applied, eliminates networking capability and restricts the devices to local monitoring.1
The ramifications of that response extend beyond the security record. The HTM team must determine whether care is dependent upon remote monitoring, coordinate with clinical users, and adhere to both the manufacturer’s and the FDA’s applicable instructions. A review remains incomplete until the operational consequences of the response have been confirmed.
The initial advisory, the manufacturer’s response, and a subsequent mitigation may each change what the hospital needs to do. As a result, advisory updates should remain integral to the response process until the related actions are completed.
Support Deadlines Should Prompt Decisions Prior
Microsoft’s Oct 14, 2025 end-of-support date for Windows 10 illustrates why lifecycle data must be included within a device’s security record. The implications vary depending on the edition and support arrangement. Systems eligible for extended security updates may continue to receive security updates, whereas long-term servicing editions possess unique lifecycle dates.2
A record that simply states “Windows 10” cannot provide a reliable basis for a decision. HTM and security teams must know the edition and version of Windows 10, the medical device manufacturer’s stance toward supporting the operating system, and whether any extended security update coverage applies. HTM and security teams should track platform support and support for the complete medical device separately.
An approaching deadline should compel a decision regarding whether to continue using the device, pursue manufacturer-supported upgrades, implement compensating controls, or replace the device. End-of-support status modifies the risk assessment; however, it does not, alone, constitute regulatory non-compliance. The record should explain the decision, who approved it, and when it will be re-evaluated.
Component Vulnerabilities Require More than Just a Model Number
A device inventory identifies equipment. Responding to a software component advisory necessitates knowing which software versions exist in each device. A software bill of materials (SBOM) can facilitate establishing that relationship, provided that the SBOM accurately depicts the software deployed.
Section 524B of the Federal Food, Drug, and Cosmetic Act mandates an SBOM as a component of applicable premarket submissions for cyber devices. FDA’s February 2026 cybersecurity guidance addresses these requirements and replaces its June 2025 guidance. Submission requirements do not signify that every legacy device in a hospital possesses an obtainable SBOM.3,4
Hospitals should request an SBOM and manufacturer disclosure statement for medical device security (MDS2) at the time of purchase, as well as provisions for receiving updated information. Link those documents to the relevant model and software release and then to individual assets. A general classification such as “infusion pumps” assists in assigning oversight but is inadequate for determining which units an advisory affects.
If software information is unattainable, document the gap and the manufacturer’s response. Component matching should initiate an assessment of applicability and exposure, followed by a decision concerning action. Component matching should not be regarded as conclusive evidence that every matched device is vulnerable.
Visibility Must Lead to Action
Claroty’s 2025 healthcare exposure study indicated devices containing known exploited vulnerabilities tied to ransomware and insecure internet connectivity were identified in 89% of the 351 healthcare organizations evaluated.5
Upon identifying an exposure, the response should link the advisory to affected assets, evaluate clinical ramifications and network exposure, designate an accountable owner, and establish a deadline commensurate with the risk. Completion requires documentation verifying that the action succeeded. For instance, following limiting a device’s network communications, verify that the limitation is effective and that all necessary monitoring and clinical interfaces continue to function.
If remediation is postponed, document why postponement occurred, interim controls utilized, and subsequent review date. Acceptance of residual risk should emanate from the organization’s designated risk acceptance authority, with clinical input where patient care is impacted. The individual maintaining the device record should not automatically be responsible for accepting that risk.
This methodology aligns with US Department of Health and Human Services guidance describing HIPAA risk analysis as an ongoing activity. Organizations must analyze changes affecting electronically protected health information and modify their protective measures accordingly. Hospitals need not await new rules to make reassessment an integral aspect of routine operations.6
Create a Record Supporting the Next Decision
The device record should aggregate information usable by HTM, IT, security, and clinical teams. At minimum, the record should designate:
- The specific asset, model, location, clinical application, and accountable owner.
- The operating system employed by the asset, its firmware, applicable software versions, and manufacturer and platform support dates.
- The network location of the asset, its authorized communications, and its reliance upon dependencies such as remote monitoring or an electronic health record interface.
- The relevant SBOM and MDS2 (including versions/dates/known information gaps).
- Existing controls, verification evidence/dates of verification/open advisories/outstanding decisions.
Security verification dates should coexist with historical inspection/maintenance data. Both are required. Additionally, earlier decisions should be retained in order for the hospital to justify what was known at a given point in time and why a particular action was taken.
A common record does not require each team to use a similar application. It does mandate consistent asset identifiers, clearly defined responsibilities for each field within the record, and a method for resolving conflicting information. A named owner coordinates responses; HTM/security/clinical teams continue to contribute their respective areas of expertise.
Initiate with a Manageable Subset of Devices
Begin with a subset of devices selected based upon clinical significance/exposure (ie, a subset of connected monitors/imaging systems). Confirm deployed versions/support dates for each device; reconcile relevant inventories; identify individuals who will evaluate/approve changes.
Route manufacturer notifications/FDA communications/relevant vulnerability advisories through an established workflow (ie, existing maintenance system) if it supports cybersecurity triage or urgent escalation. Initiate review whenever software or connectivity changes occur following relevant third-party service prior to support deadlines. Conduct periodic checks to detect missed events or incomplete information.
Measure time required to identify affected assets, evaluate an advisory, and confirm remediation (grouped by risk priority). Track initial containment separately from permanent remediation, overdue actions, and exceptions awaiting review. Rapid evaluation is beneficial only if it results in timely action addressing exposure.
Hospitals should be capable of demonstrating which devices were affected, what action was taken, and how results were verified. When clinical teams can verify that patient care requirements are satisfied, security teams can demonstrate intended controls functioned effectively. Then the record provides verification of successful completion of response.
References
- US Food & Drug Administration. Cybersecurity Vulnerabilities with Certain Patient Monitors from Contec & Epsimed. Safety Communication. January 30, 2025; Revised 2025 July 2
- Microsoft. Extended Security Updates Program for Windows 10
- US Food & Drug Administration. Cybersecurity In Medical Devices Frequently Asked Questions
- US Food & Drug Administration. Cybersecurity In Medical Devices Quality Management System Considerations and Content of Premarket Submissions. Final Guidance Document. 2026 February
- Claroty’s State of CPS Security Report Healthcare Exposures 2025
- US Department of Health & Human Services. Guidance On Risk Analysis
ID 459993915 © Stockvectorwin | Dreamstime.com
About the author: Kaarthick Subramanian is Chief Customer Officer and CISO at Atlas Systems. He built the company’s security function, including its 24/7 security operations, and leads security strategy, enterprise risk, compliance, third-party risk, and customer assurance for Fortune 500 and PE-backed clients across healthcare, pharma, and financial services. He holds the CISSP and has more than 20 years of experience leading global technology and services portfolios.
