The Hospital Supply Chain Includes the Device Software

Article ID: NU54-044
Section: Hot
Slug: medical-device-cybersecurity-lifecycle
Prepared: 31 October 2026
Evidence checked: 31 October 2026
Dek: A connected device arrives with software dependencies, maintenance assumptions and a support horizon. Hospitals need to purchase and manage those capabilities as deliberately as the physical equipment.

The delivery includes years of future decisions

A hospital can inspect a newly delivered device, confirm that it performs its intended function and still know too little about how it will be maintained five years later. The missing information may concern an embedded operating system, a remote service account, a software library or the manufacturer's ability to produce and validate updates. Those dependencies are part of the supply chain even when they do not arrive in a separate box.

On 3 February 2026, the US Food and Drug Administration issued its current guidance on cybersecurity in medical devices, replacing the June 2025 version. The document addresses design, labeling and premarket documentation, including recommendations related to statutory requirements for cyber devices. Its title now refers to quality management system considerations. The date matters: an old procurement template citing the prior guidance may no longer identify the current document. The guidance itself contains nonbinding recommendations and must be distinguished from the legal requirements it discusses. FDA's February 2026 guidance.

The broader operational problem is not solved when a device receives authorization for marketing. Hospitals use equipment in changing networks, alongside other systems, under real clinical constraints. Vulnerabilities may be discovered after deployment. A component supplier may end support. A manufacturer may release an update that requires testing, scheduling and staff coordination. The device's safe use depends partly on how these changes are handled.

This article examines that lifecycle from procurement to retirement. It does not advise patients to disconnect, modify or stop using any device, and it does not provide clinical or regulatory advice for a particular product. The scenarios are hypothetical. Decisions affecting patient care require the hospital's clinical, biomedical engineering, cybersecurity and manufacturer teams to assess the actual equipment and circumstances together.

The evidence question is practical: can the organization trace a device from its current clinical role through its software state, network dependencies, available mitigations and support commitments? Without that chain, a hospital may own functioning hardware while lacking a workable plan to keep its digital components trustworthy.

Inventory must identify the configuration in use

A purchase ledger can establish that a hospital owns fifty units of a particular model. It may not establish which software version each unit runs, where it is currently located, whether it is connected or which management server controls it. Cybersecurity decisions often depend on those details rather than on the model name alone.

A useful device inventory links physical identity, software state and operational context. The physical record includes model and serial information. The software record includes relevant versions and update history. The operational record identifies the service, owner, location and network relationships. These records may live in different systems, but they need a reliable way to refer to the same asset.

Consider a hypothetical hospital with twenty devices sharing a model name. Twelve received a software update during annual maintenance, five remain on the previous version and three are loan units from a supplier. A vulnerability notice affects only one configuration. A model-level search can overestimate or underestimate exposure, depending on how the hospital interprets the missing version information.

Discovery methods have limits. Passive network observation may identify connected devices without disturbing them, but it may miss disconnected equipment or misidentify a device behind a gateway. Procurement records may capture ownership while missing loaners, research equipment or devices brought in through a clinical department. Physical inspection can verify labels but may not reveal all software components. Reconciliation across methods is more reliable than treating any one list as complete.

The inventory should record uncertainty explicitly. Unknown software version is a state requiring follow-up, not a synonym for unaffected. A device that has not appeared on the network for months may be retired, stored, isolated or simply unobserved. Removing it automatically from the inventory can erase an asset that later returns to service.

The most useful measure is therefore not the raw number of discovered devices. It is the proportion of clinically relevant assets for which the hospital can answer the questions needed for a specific decision. When a notice arrives, can the team locate the affected units, establish their configurations and identify the people authorized to act? That capability turns inventory from an accounting exercise into operational evidence.

The device sits inside a larger clinical system

A connected medical device may depend on a management server, an electronic record interface, a directory, a wireless network, a time service and a remote support connection. Some dependencies affect convenience; others affect essential functionality or the availability of information used in care. A risk assessment needs to identify which is which.

NIST's 2018 practice guide on wireless infusion pumps examines an ecosystem rather than treating the pump as an isolated object. Its example implementation uses commercially available controls to address risks involving devices, servers, networks and information. The guide is a laboratory-based reference architecture, not evidence that every hospital using similar equipment has achieved the same result. NIST SP 1800-8.

A hypothetical device continues its local function when the network fails but cannot send data to the clinical record. That may preserve one aspect of care while creating another risk: staff may assume the record is current when it is not. A different device may require a network service for a critical workflow. The same firewall change can therefore have different consequences across devices.

The dependency map should distinguish data flows from administrative authority. A server may receive measurements without having permission to change device settings. Another may distribute configurations or software. These relationships imply different consequences if the server becomes unavailable or compromised. A simple connected-to diagram can conceal that difference unless the purpose and direction of each relationship are recorded.

Time and identity are easy dependencies to overlook. Certificates can expire, clocks can drift and authentication services can fail. The resulting outage may look like a device fault even though the physical equipment is intact. Testing should include these surrounding services where they affect the intended workflow.

A clinical-system view also improves incident prioritization. A vulnerability in a device used only in a controlled laboratory may present a different exposure from the same vulnerability in an internet-reachable support system. The technical weakness remains relevant, but its pathway to patient or service harm depends on the environment. The hospital needs that context before choosing among patching, isolation, monitoring, replacement or another authorized response.

A vulnerability notice is the start of triage

A notice that a component contains a vulnerability does not establish that every device containing it is exploitable in the same way. The affected code may be absent from the deployed configuration, disabled, inaccessible or protected by another control. Conversely, a device may be exposed through a dependency not obvious from its product label. Triage connects the technical finding to the actual system.

The first step is version and configuration matching. The next is understanding the conditions required for exploitation and the possible consequences. Does the issue require local access, an authenticated account or network reachability? Could it affect confidentiality, availability, data integrity or a clinical function? What mitigations are supported by the manufacturer? These questions should be answered from reliable information rather than inferred from a severity label alone.

A hypothetical advisory describes a serious flaw in a network service included in a device's operating system. The manufacturer says the service is disabled in one software release but enabled in another. The hospital's inventory does not distinguish the releases. The immediate evidence gap is configuration identification, even before the team can make a defensible decision about deployment of a patch.

Component information, including a software bill of materials where available, can help locate possible exposure. It is a starting point for analysis rather than a declaration that a product is unsafe. This article does not attempt a general treatment of software inventories; the hospital-specific question is whether component information can be connected to the exact deployed device and its supported remediation path.

The triage record should preserve the manufacturer's statement, the hospital's observed configuration and any unresolved disagreement. A statement that a vulnerability is not exploitable should identify the assumptions supporting that conclusion. If a later configuration change invalidates one of those assumptions, the risk decision needs review.

A closed ticket should mean that a defined disposition has been reached, not merely that someone read the advisory. The disposition might be patched and verified, unaffected with supporting evidence, temporarily mitigated with an expiry date, or unresolved pending manufacturer information. Those categories let clinical and technical leaders see what has actually changed and where uncertainty remains.

Security updates require clinical change management

Patching a medical device is not identical to updating an ordinary office computer. The update may affect a validated configuration, communication with other equipment or a workflow that cannot be interrupted without planning. These constraints do not justify indefinite inaction. They require a process that evaluates both the risk of the vulnerability and the risk of the change.

FDA's December 2016 postmarket guidance recommends managing cybersecurity across the product lifecycle and addressing vulnerabilities after devices are marketed. Its central operational premise is continuing maintenance, not a one-time assurance at sale. The document should be read as guidance within its stated scope, rather than as a universal rule that every software change requires the same regulatory process. FDA postmarket guidance.

A hypothetical update is available for a device used continuously in a busy clinical area. The hospital needs to know whether the update requires downtime, whether settings are preserved, whether rollback is supported and what functional checks are required afterward. It also needs enough replacement capacity or scheduling flexibility to keep the clinical service operating safely during the work.

Testing should reflect the deployed environment. A manufacturer may validate core device behavior, while the hospital needs to check local interfaces and workflows. If an update changes a communication protocol, the device may pass its own tests while failing to exchange information with a local integration engine. The responsibilities overlap but are not identical.

The record should distinguish release availability from deployment completion. A patch posted on a portal has not yet protected a hospital's installed fleet. Between release and completion lie notification, assessment, acquisition, testing, scheduling, installation and verification. Measuring only the first date can conceal a long period of practical exposure.

Rollback also deserves scrutiny. Returning to the prior version may restore functionality while reintroducing the vulnerability. A safe change plan should state the conditions under which rollback is appropriate and what temporary protections are needed afterward. The organization should avoid treating rollback as a consequence-free escape route or treating deployment as complete before the clinical owner accepts the restored function.

The word legacy should describe supportability

Old equipment is not automatically insecure, and new equipment is not automatically supportable. The relevant issue is whether the device can be reasonably protected against current threats while maintaining its intended function. A relatively new product can become difficult to secure if a critical component loses support or if the design prevents necessary updates.

The International Medical Device Regulators Forum's April 2023 legacy-device guidance makes this distinction explicit and presents lifecycle stages involving development, support, limited support and end of support. It emphasizes shared risk management and communication across those stages. The document is international technical guidance, not a substitute for each jurisdiction's requirements. IMDRF legacy-device guidance.

A hypothetical imaging system remains mechanically reliable after its embedded operating system reaches end of support. Replacing the operating system may require manufacturer engineering and validation that the hospital cannot perform independently. The hospital now faces a lifecycle problem involving continued clinical value, exposure, compensating controls and replacement timing. Calling the system old does not resolve any of those questions.

Support status should be broken into capabilities. Does the manufacturer still accept vulnerability reports? Provide security updates? Test compatibility with supported infrastructure? Supply replacement components? Offer emergency engineering assistance? A service contract covering mechanical repairs may not include every cybersecurity function the hospital assumes it includes.

The timeline should identify notice periods and decision points. If support ends in eighteen months, the hospital may need procurement, budgeting, installation and training work to begin well before then. Waiting until the final month can force a choice between abrupt service disruption and continued use without a satisfactory protection plan.

The inventory should retain the basis for support-status judgments. A salesperson's informal reassurance is weaker than a documented commitment tied to the model and software release. Where the manufacturer cannot provide a firm horizon, that uncertainty belongs in acquisition and replacement planning. The organization is buying a future maintenance relationship as well as equipment that works today.

Compensating controls need a mechanism and a test

When a device cannot be patched promptly, the organization may consider controls around it. Network restrictions, controlled remote access, monitoring and physical safeguards can reduce particular exposure paths. Their usefulness depends on the threat mechanism and the device's operational requirements. A control is not compensating merely because it sounds protective.

A hypothetical device is vulnerable through a service reachable only from a management network. Restricting access to that service may reduce risk if the restriction is correctly enforced and the remaining authorized systems are trustworthy. The control would not address a separate vulnerability triggered by a removable medium or a local interface. The risk assessment should connect each mitigation to the pathway it actually interrupts.

Segmentation is especially easy to overstate. Placing a device in a named network zone does not establish that communication is restricted as intended. Firewall rules, routing, management access and exceptions determine the effective boundary. An authorized test should verify required flows and blocked flows without placing clinical operations at risk.

The Health Sector Coordinating Council's March 2023 guide on managing legacy technology addresses responsibilities and practices across healthcare delivery organizations and manufacturers. It provides a structured way to consider legacy risk rather than treating unsupported technology as a purely local technical problem. As an industry-developed guide, it is useful primary evidence of the sector's proposed practices, not a binding standard or proof of adoption. HIC-MaLTS.

Temporary controls should have review dates and exit conditions. If a mitigation is accepted while waiting for a patch, the record should state what evidence would trigger reassessment: a new exploit, a configuration change, a failed control test or arrival of the update. Otherwise temporary can become indefinite through administrative inertia.

The clinical impact must also be tested. A restriction that blocks a required data flow may reduce cyber exposure while creating a workflow hazard. That does not mean the restriction should be abandoned automatically. It means the design needs to be evaluated jointly and adjusted until the organization understands both the protection and the operational consequence.

Remote support is a supply chain relationship

A manufacturer or service provider may need remote access to diagnose faults, update software or maintain equipment. That access can be valuable, especially where specialist expertise is scarce. It also creates an authority path from an external organization into the hospital's clinical environment.

The hospital should understand who can initiate a session, how identity is verified, what privileges are granted and how the session is recorded. Access limited to an approved maintenance window differs from continuously available access. A shared support account differs from individually attributable access. These distinctions affect both prevention and the ability to reconstruct what happened after an incident.

A hypothetical supplier uses one remote support system for several hospital customers. If that system is compromised, the consequences can extend beyond a single device. The hospital cannot assess the relationship solely by testing the device's local password. It needs assurance about the provider's access model and a way to suspend or constrain the connection when necessary without losing essential service support.

Contracts can specify notification, access approval, logging and termination processes, but the operational configuration must match. A clause requiring hospital approval has little practical effect if the vendor can connect through an undocumented channel. Periodic reconciliation between authorized paths and observed connections can reveal that mismatch.

The support process should also work during an emergency. If the normal approval system is unavailable, an alternate procedure needs clear authority and limits. Improvised broad access under pressure can create new uncertainty just as the hospital is trying to contain an incident. The fallback should be designed and exercised in advance.

Ending a supplier relationship requires technical follow-through. Accounts, credentials, tunnels, management agents and notification contacts may remain after a contract ends. A procurement record marked terminated does not establish that access was removed. The closure evidence should include the relevant technical checks and ownership of any continuing support obligation.

Safety and security share consequences without sharing every metric

A cybersecurity severity score summarizes technical characteristics under a particular scoring method. It does not directly quantify the probability or severity of patient harm in a specific hospital. Clinical consequences depend on the device's role, exposure, workflow, safeguards and available alternatives. The score is useful input, not the final prioritization decision.

Health Canada's 2019 premarket cybersecurity guidance treats device cybersecurity vulnerabilities as potential patient risks and discusses design and mitigation practices. Its regulatory context is Canadian and should not be silently imported into US requirements. It illustrates the broader principle that security evidence must connect to safety and effectiveness rather than remain a separate information-technology checklist. Health Canada guidance.

A hypothetical vulnerability could interrupt data transfer without changing the device's local operation. In one workflow, staff routinely verify the local display and can continue safely. In another, remote information is central to timely action. The same technical effect can therefore have different clinical implications. A risk assessment needs to describe the actual workflow rather than assume that every loss of connectivity has the same consequence.

The reverse problem also matters. A technically modest weakness can become important if it affects a critical service with few alternatives. A hospital may prioritize it ahead of a higher-scoring issue on an isolated, noncritical system. That prioritization should be documented so the reasoning can be reviewed rather than mistaken for neglect of the score.

Uncertainty should remain visible. The hospital may not know whether a particular failure mode can occur under its configuration. A conservative temporary measure may be appropriate while the manufacturer investigates, but the decision should distinguish observed behavior from a plausible scenario. Claims that a device has been exploited or that patients were harmed require evidence of those events, not merely the existence of a vulnerability.

Joint assessment helps prevent siloed decisions. Cybersecurity staff can describe exposure and threat pathways. Biomedical engineers can explain device behavior and support constraints. Clinicians can describe the consequences of downtime or changed workflow. Manufacturer specialists can provide design information. The decision improves when these contributions remain specific and testable rather than being reduced to competing labels of safe or unsafe.

Procurement determines future options

Many lifecycle problems become expensive because the hospital discovers them after purchase. Procurement is the point at which support commitments, update methods, documentation and integration requirements can be clarified before the organization becomes dependent on the equipment. The lowest acquisition price may not produce the lowest supported lifetime cost.

A hypothetical comparison involves two devices with similar clinical capabilities. One has a clear security-support horizon, documented update procedures and a tested method for exporting configurations. The other offers a lower purchase price but uncertain support beyond the initial contract. A lifetime comparison should include the cost of compensating controls, staff effort and potential early replacement, not only the invoice.

The buyer can ask for evidence of how vulnerability reports are received and handled, how customers are notified, how patches are delivered and what happens when a component supplier stops support. The answer should identify responsibilities and timelines in terms that can be evaluated. A general statement that security is a priority does not establish a maintenance capability.

Acceptance testing should include the hospital's intended integration and security configuration. If the device requires broad network access or privileged accounts, those requirements should be discovered before installation becomes urgent. If the manufacturer supports only a specific configuration, that boundary should be documented so later local changes are reviewed appropriately.

The contract should distinguish security updates from feature upgrades and clarify which costs are included. A hospital may otherwise discover that addressing a vulnerability requires purchasing a larger software release or replacing hardware. This article does not prescribe contractual language; it identifies questions whose answers affect the institution's future options.

Exit planning belongs at acquisition too. The hospital needs to know how patient data, configurations and logs can be exported or removed, what happens to remote access and how the device can be decommissioned safely. A product that is easy to install but difficult to retire can impose costs long after its clinical role changes.

Regulatory requirements have a defined scope

FDA's public FAQ explains that section 524B applies to specified premarket submissions for devices meeting the statutory definition of a cyber device. It describes requirements involving vulnerability-management plans, processes for cybersecurity and updates, and software component information. It also explains that the requirements do not apply to submissions made before 29 March 2023, while a later change requiring a new premarket submission can bring the new submission within scope. FDA's cyber-device FAQ.

That scope matters for public discussion. A statement that every device already in a hospital must immediately satisfy every new submission requirement would overstate what the FAQ says. A statement that older devices need no cybersecurity management would also be wrong as an operational conclusion. Regulatory submission rules and the hospital's ongoing risk-management needs are related but distinct.

A manufacturer should determine its obligations using the applicable law, guidance and regulatory advice. A hospital should not infer a product's current security solely from the date of its clearance or approval. Authorization establishes a regulatory status under a particular pathway; it is not a perpetual guarantee against newly discovered vulnerabilities or unsafe local configuration.

The distinction between guidance and law should be preserved in reporting. A guidance document can explain recommended approaches and discuss binding requirements without making every recommendation independently mandatory. Readers need to know which proposition comes from statute, which from agency recommendation and which is an author's proposed procurement practice.

This article intentionally avoids adjudicating compliance for any named product or institution. Such a determination would require the device, submission history, applicable requirements and actual conduct. The more useful general question is whether the parties can produce the evidence needed to assess their responsibilities and manage the equipment over time.

A well-run organization can exceed a minimum submission requirement where its operational risk warrants it. It can also recognize that a requirement aimed at a manufacturer does not automatically transfer a complete implementation process to the hospital. Shared responsibility requires explicit coordination, not an assumption that the other party's regulatory obligations cover every local task.

A notice must reach the people who can act

Vulnerability disclosure and customer notification are practical communication systems. A notice sent to an obsolete purchasing address may satisfy an internal mailing process while failing to reach biomedical engineering or the clinical service. The hospital needs a maintained route from manufacturer information to the people who can identify affected assets and decide on action.

FDA's cybersecurity resource page brings together guidance, safety communications and related material. Its existence is useful for locating official information, but hospitals still need internal processes to connect a published notice to their own installed equipment. Reading a public page is not the same as completing an affected-device review. FDA cybersecurity resources.

A hypothetical notice identifies a model family and a set of software releases. The hospital's purchasing system uses a different product description, and its device inventory omits the software field. The communication failure occurs at the join between records. A human analyst can resolve it, but only if the notice enters a queue with an owner and a completion criterion.

The response should record the affected count, unaffected count and unknown count. Unknown units require follow-up rather than disappearing from the report. Loaned, leased and vendor-managed devices should be included where they are used in the clinical environment, even if another party owns them.

Manufacturers also need feedback. A hospital may discover that a proposed mitigation is incompatible with a local integration or that a patch fails on a particular configuration. The information should reach the manufacturer's technical team through a documented channel, with enough detail to reproduce the problem and without unnecessary patient information.

Public communication needs precision. A hospital can explain that it is assessing a vulnerability without claiming an attack occurred. It can describe service disruption without attributing it to a cyber cause before evidence supports that conclusion. Clear distinctions reduce confusion and make later updates easier when the technical picture changes.

Replacement is a capacity decision as well as a budget decision

A hospital may know that a device should leave service but be unable to replace an entire fleet immediately. Replacement requires capital, procurement time, installation, integration, training and clinical capacity during transition. A plan that ignores those constraints can be as unrealistic as one that ignores the cybersecurity risk.

A hypothetical fleet contains sixty devices, of which ten support a highly constrained service. Replacing all sixty at once would reduce clinical capacity during installation. A phased plan might prioritize the most exposed or least supportable units while maintaining temporary controls elsewhere. The prioritization should consider actual risk and service dependencies rather than age alone.

Replacement can introduce new risks. Staff need to learn a new interface, data must migrate and integrations must be validated. A newer device may offer better security features but require configuration choices that the hospital has not yet implemented. The transition's success should be measured by supported operational capability, not by the delivery of new boxes.

Lifecycle costing should include the residual work on the old fleet. Devices awaiting retirement still need monitoring, access control and maintenance appropriate to their use. Declaring them scheduled for replacement does not reduce their present exposure. The plan needs interim owners and review dates.

Retirement itself requires evidence. Patient information and credentials may remain on storage. Remote support accounts may still exist. An asset sold, donated or returned to a supplier can carry data or access relationships beyond the hospital if the process is incomplete. Decommissioning should follow the device's supported procedures and applicable requirements, with verification that the intended actions occurred.

The final inventory event should connect the physical disposition, data handling, access removal and contract closure. That record helps prevent a retired device from reappearing as an unexplained network asset or an unresolved support obligation. It also completes the lifecycle that procurement began, making future purchasing decisions better informed by the actual cost and effort of safe retirement.

The handoff needs a shared evidence packet

The hospital and manufacturer each know things the other needs. The manufacturer understands design assumptions, supported configurations and component dependencies. The hospital understands local networks, workflows, exposure and clinical consequences. A useful handoff transfers enough information to manage the interface without expecting either party to reveal unrelated sensitive details.

For a hypothetical new deployment, the packet could identify the supported software release, network requirements, administrative roles, update procedure, logging capabilities, backup and recovery expectations, vulnerability contact and support horizon. The hospital would add its local owner, location, approved configuration and acceptance-test results. These are proposed evidence fields, not a claim that every jurisdiction mandates one standardized packet.

The packet should be versioned. A software update, integration change or support-status transition can alter its assumptions. If the hospital keeps only the original installation document, later decisions may rely on conditions that no longer exist. A change record can show what changed, who reviewed it and which tests were repeated.

Evidence of a control should include its limitation. A device may support encrypted communication on one interface but use a different protocol on another. It may log administrative changes but not retain them long enough for the hospital's investigation needs. A precise description allows the surrounding system to compensate where necessary; a broad security claim can conceal the gap.

The packet can also support emergency coordination. During an incident, responders need to know which actions could affect clinical function and whom to contact for device-specific guidance. That information should be accessible through an authorized path even if ordinary communications are unavailable. The plan should not depend on finding a particular salesperson or searching an inaccessible mailbox.

The goal is continuity of knowledge across the device's life. People change roles, suppliers reorganize and systems evolve. A shared, maintained evidence packet makes the organization less dependent on individual memory and more capable of explaining why a device remains suitable for its current environment.

Fleet metrics should preserve the unresolved group

A remediation percentage can look reassuring while concealing the devices most difficult to manage. If a hospital reports that ninety percent of affected units are patched, the remaining ten percent may be lightly used spares or the most critical devices in continuous operation. The percentage does not reveal that distinction. A useful report groups the remainder by clinical role, exposure, available mitigation and reason for delay.

A hypothetical fleet has one hundred affected units. Eighty are updated, ten are temporarily isolated, five are awaiting a manufacturer fix and five cannot yet be located. Reporting ninety percent treated may be reasonable under a defined metric, but it should not become ninety percent patched. The categories describe different states and different residual risks. The five unlocated units should remain visible until their disposition is established.

Elapsed time should also be decomposed. Time from public disclosure to manufacturer assessment differs from time from patch release to hospital installation. The first may reflect engineering uncertainty; the second may reflect local scheduling, testing or resource constraints. Combining them into one number can obscure where the delay occurred and which organization can reduce it.

The report should include verification. An installation tool's success message may not establish that the device is running the intended version after restart or that its clinical integration still works. A completed change needs both technical confirmation and the relevant functional acceptance. Where verification is sampled rather than comprehensive, the sampling scope should be stated.

Finally, the metric should follow exceptions to closure. A temporary network restriction can remain effective, fail after a network change or become unnecessary when a patch arrives. The hospital should not repeatedly count the original approval as fresh evidence. Review dates, observed configuration and the reason for continued exception make the residual group manageable. Without them, the dashboard can improve while the hardest problems remain unchanged beneath a more favorable label.

The maintained device is the purchased product

The physical device, its software and the support relationship form one operational package. A hospital that evaluates only the hardware can miss the dependencies that determine whether the equipment remains usable and protectable over time. The software supply chain becomes visible when a vulnerability, expired component or support transition forces a decision.

The strongest response begins before that moment. Procurement establishes support expectations. Inventory connects the actual configuration to the clinical role. Triage interprets new findings in context. Change management tests updates and local integrations. Temporary controls have mechanisms, owners and review dates. Replacement and retirement are planned as service transitions rather than isolated purchasing events.

None of these steps implies that every vulnerability produces patient harm or that every legacy device must be removed immediately. Those conclusions require case-specific evidence. The discipline is to make uncertainty and responsibility explicit, so that continued use, mitigation or replacement rests on a documented assessment rather than habit.

The February 2026 FDA guidance is a timely reminder that the regulatory and technical context continues to change. The hospital's installed fleet does not change at the same speed. Managing the gap requires sustained coordination among manufacturers, clinical teams, biomedical engineering, information technology and security staff.

A useful procurement question therefore reaches beyond what the device can do on delivery day: what evidence and support will let this hospital keep using it responsibly throughout its intended life? The answer belongs in the buying decision, the maintenance plan and the eventual exit. The hospital supply chain includes every software dependency and service commitment needed to make that answer credible.