Medical Device Lifecycle Management

Medical Device Lifecycle Management (HICP Practice 9.7) requires you to manage cybersecurity controls for medical devices from procurement through decommissioning, including end-of-life planning. To operationalize it fast, build a device lifecycle workflow that ties purchasing requirements, inventory, vulnerability management, compensating controls, and retirement steps into one auditable process. ¹

Key takeaways:

• Treat medical devices as lifecycle-managed assets: buy securely, operate securely, retire securely. ¹
• Make end-of-support and end-of-life a planned event, not a surprise outage or risk acceptance scramble. ¹
• Evidence matters: you need artifacts that prove security requirements were set, risks were tracked, and devices were securely decommissioned. ¹

Medical devices often sit in the hardest part of your environment: clinical workflows that cannot tolerate downtime, legacy operating systems, specialized third-party support, and network constraints that make standard endpoint controls unrealistic. HICP Practice 9.7 addresses that reality by requiring lifecycle cybersecurity management, not one-time “secure onboarding.” ¹

For a Compliance Officer, CCO, or GRC lead, the operational goal is straightforward: make device security predictable across the device’s lifespan and make decisions traceable. That means procurement gates that prevent risky devices from entering the environment without a plan, operational controls that keep deployed devices monitored and protected, and decommissioning steps that prevent data exposure or “zombie assets” with lingering connectivity. ¹

This page translates the requirement into a practical workflow you can stand up quickly with Security, Clinical Engineering/Biomed, IT, Supply Chain, and the relevant third parties (manufacturers, service providers, and managed maintenance partners). It also calls out the artifacts auditors ask for and the mistakes that cause programs to fail in practice. ¹

Regulatory text

HICP Practice 9.7 (excerpt): “Manage the cybersecurity lifecycle of medical devices from procurement through decommissioning, including end-of-life planning.” ¹

What this means for an operator: you must run a repeatable lifecycle process that starts before purchase (security requirements and risk review), continues through deployment and operations (inventory, vulnerability management, compensating controls, supportability), and ends with secure retirement (data handling, access removal, and disposal). End-of-life and end-of-support cannot be handled ad hoc; they must be planned as part of lifecycle management. ¹

Plain-English interpretation (requirement-level)

You need a documented, followed process that:

1. prevents unmanaged or unsupported medical devices from being introduced without a security plan,
2. maintains an accurate inventory and security posture for each device while in service, and
3. ensures devices are safely removed, wiped, and disconnected at end of life. ¹

If you cannot patch or install agents (common for medical devices), HICP 9.7 still expects you to manage risk. In practice, that means network segmentation, strict access control, monitoring, and compensating controls tied to a tracked risk decision. ¹

Who it applies to

Applies to:

• Healthcare organizations that own, operate, or connect medical devices to clinical networks, enterprise networks, or patient data environments. ¹
• Health IT vendors and other third parties who provide device platforms, device software, remote servicing, monitoring, or managed maintenance where they influence cybersecurity across the device lifecycle. ¹

Operational contexts where this becomes urgent:

• Devices connected to your network (wired, Wi‑Fi, cellular, VPN, remote support links). ¹
• Devices that store, process, or transmit sensitive clinical data. ¹
• Devices with known constraints: unpatchable OS, hard-coded dependencies, or proprietary servicing requirements. ¹

What you actually need to do (step-by-step)

1) Define lifecycle ownership and the “one workflow”

Action steps

1. Assign a lifecycle owner (often Clinical Engineering/Biomed with Security + IT governance).
2. Create a RACI that covers procurement, deployment, operations, and retirement.
3. Standardize one intake workflow for “new device / new model / major software update” so nothing bypasses review. ¹

Practical tip: If teams keep buying outside Supply Chain, you will fail lifecycle management. Add a purchasing control: “no PO without device security intake completed.”

2) Build medical device security requirements into procurement

Action steps

1. Add minimum cybersecurity requirements to RFIs/RFPs and purchasing terms (authentication options, logging, encryption where applicable, secure update mechanisms, support commitments, vulnerability disclosure expectations, remote access controls, and SBOM/technical documentation if available). ¹
2. Require the third party to disclose end-of-support timelines and servicing model before purchase. ¹
3. Perform a risk review prior to purchase for connectivity, data flows, and deployment environment. Document compensating controls if the device cannot meet requirements. ¹

Exam focus: auditors look for proof you addressed security before onboarding, not after an incident.

3) Maintain an accurate inventory tied to lifecycle status

Action steps

1. Inventory each device/model with: owner, location, network segment, connectivity method, software/firmware version, support contact, patch method, and lifecycle dates (install date, expected refresh window, end-of-support, end-of-life). ¹
2. Tag devices by risk attributes (internet-reachable, remote service enabled, stores patient data, unpatchable). ¹
3. Ensure the inventory is reconciled with procurement records and network discovery so it does not drift. ¹

Tooling note: Many programs run this from CMDB + biomed inventory + network discovery. Daydream can help you convert your lifecycle requirement into a control narrative and evidence checklist you can assign across teams, then track completion and artifacts in one place.

4) Operationalize vulnerability and change management for devices

Action steps

1. Establish how you receive vulnerability and safety/security notices (manufacturer bulletins, service provider alerts, internal scanning where safe). ¹
2. Define a triage path that includes Clinical Engineering and Security to decide: patch, mitigate, isolate, or accept risk with compensating controls. ¹
3. Maintain device-specific change windows and validation steps so security changes don’t break clinical performance. ¹

What auditors ask: “Show me how you track a device vulnerability from identification to closure.”

5) Control remote access and third-party servicing

Action steps

1. Inventory all remote access paths (VPN, cloud portals, modem/cellular, vendor remote support tools) for each device category. ¹
2. Require approved remote access methods, documented approvals, access logging, and a termination process when contracts end or devices retire. ¹
3. Confirm who has admin credentials, how they are managed, and how emergency access is handled. ¹

6) Make end-of-support/end-of-life planning an operational trigger

Action steps

1. Track end-of-support and end-of-life dates in inventory and set internal triggers for replacement planning. ¹
2. When a device becomes unsupported, require a documented decision: replace, isolate with compensating controls, or temporarily accept risk with time-bound remediation planning. ¹
3. Maintain a clinical-safe contingency plan for devices that cannot be replaced quickly (spares, workflow alternatives, downtime procedures). ¹

7) Decommission securely (and prove it)

Action steps

1. Remove the device from networks and management systems (DNS, DHCP reservations, NAC policies, monitoring, remote access allowlists). ¹
2. Handle data: wipe, sanitize, or destroy storage per your policy and device capabilities, and document what was done. ¹
3. Recover credentials, certificates, and tokens; disable service accounts used for maintenance. ¹
4. Update inventory status to “retired” with decommission date and disposal method. ¹

Required evidence and artifacts to retain (audit-ready)

Maintain a package that ties each lifecycle phase to proof:

Procurement

• Device cybersecurity requirements checklist included in sourcing
• Third-party security documentation received and reviewed
• Approval record (or risk acceptance with compensating controls) ¹

Deployment / configuration

• Network segmentation or placement decision
• Baseline configuration standard (passwords, services, logging, remote access settings)
• Implementation/change record ¹

Operations

• Inventory with lifecycle fields populated
• Vulnerability/patch tracking tickets and closure evidence
• Remote access approvals and logs (where applicable)
• Exception/risk acceptance register with review notes ¹

End-of-life / decommissioning

• Decommission checklist completed
• Data sanitization/destruction record
• Confirmation of access removal and inventory update ¹

Common exam/audit questions and hangups

• “How do you know what medical devices you have, where they are, and who owns them?” ¹
• “Show the workflow that blocks purchase/onboarding until security review is complete.” ¹
• “How do you manage devices that cannot be patched?” Expect follow-ups on compensating controls and documented risk decisions. ¹
• “What is your process for end-of-support devices?” The hangup is usually missing lifecycle dates and no replacement plan. ¹
• “Prove that decommissioned devices are removed from remote access and monitoring.” Many teams wipe the device but forget the access path. ¹

Frequent implementation mistakes (and how to avoid them)

1. Inventory without lifecycle fields. Fix: require end-of-support/end-of-life fields for new devices and backfill high-risk categories first. ¹
2. Security review after installation. Fix: add a procurement gate tied to PO creation. ¹
3. “Unpatchable” becomes “unmanaged.” Fix: define standard compensating controls (segmentation, strict access, monitoring) and require a tracked exception when they can’t be met. ¹
4. Remote access sprawl. Fix: centralize approved remote access patterns and maintain an inventory of remote pathways per device type. ¹
5. Decommissioning stops at disposal. Fix: make decommissioning include network removal, credential revocation, and inventory closure. ¹

Enforcement context and risk implications

HICP is a healthcare cybersecurity practices framework, and this requirement is framed as operational risk reduction rather than a single technical control. Your exposure comes from predictable failure modes: unsupported devices, unmanaged remote access, incomplete inventories, and devices retired without verified data handling. Treat lifecycle evidence as your defensive file: it shows governance, repeatability, and risk decisions tied to clinical constraints. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop new gaps)

• Stand up a cross-functional RACI and name a lifecycle owner. ¹
• Add a procurement gate: no purchase/onboarding without a documented security intake. ¹
• Define the minimum device inventory fields, including end-of-support/end-of-life. ¹
• Identify “top risk” device categories (connected, remote access, patient data, unpatchable) and prioritize them for backfill. ¹

Next 60 days (operational workflows and evidence)

• Implement vulnerability intake and triage workflow for medical devices with ticketing and closure evidence. ¹
• Standardize compensating controls for constrained devices (segmentation, access restrictions, monitoring) and require documentation for exceptions. ¹
• Inventory remote access paths by device class; require approvals and a termination step. ¹

Next 90 days (end-of-life readiness and audit packaging)

• Build the end-of-support/end-of-life trigger process and align it with budgeting and replacement planning. ¹
• Roll out a decommission checklist with required sign-offs (Clinical Engineering + IT/Security). ¹
• Assemble an audit-ready evidence pack: procurement artifacts, inventory exports, vulnerability tickets, risk acceptances, and decommission records. ¹
• If you are coordinating across many device types and third parties, Daydream can help by mapping HICP 9.7 into assigned tasks, collecting artifacts, and producing a consistent control narrative for audits.

Frequently Asked Questions

Does HICP Practice 9.7 require us to patch every medical device immediately?

HICP 9.7 requires lifecycle cybersecurity management, which includes vulnerability management and end-of-support planning. If patching is constrained, document the decision and implement compensating controls and a replacement or mitigation plan. ¹

What’s the minimum inventory data we need to show lifecycle management?

You need enough to connect each device to ownership, connectivity, software/firmware state, and lifecycle dates like end-of-support/end-of-life. Auditors also expect you to show where the device sits on the network and how it is maintained. ¹

Our devices are managed by a third-party service provider. Are we still responsible?

Yes. You can outsource tasks, but you still need governance: procurement requirements, visibility into support status, and evidence that vulnerabilities and end-of-life are managed. Treat the service provider as a third party whose controls you must verify. ¹

What should we do about devices that are end-of-support but clinically necessary?

Require a documented risk decision with compensating controls and a time-bound replacement or redesign plan. Track the device explicitly as an exception so it does not disappear into normal operations. ¹

How do we prove secure decommissioning in an audit?

Keep a completed decommission checklist that includes network removal, access revocation, and documented data sanitization or destruction. Update the inventory status to retired with the date and disposal method. ¹

Can we satisfy the requirement with policy only?

Policy helps, but HICP 9.7 is operational. Auditors will ask for workflow evidence: intake records, inventory fields, vulnerability tickets, risk acceptances, and decommission documentation. ¹

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices