Accountability should sit jointly with security, clinical engineering, and operations, because legacy medical devices are governed by both patient-safety requirements and cybersecurity risk. Organisations need named owners for exceptions, documented compensating controls, and review cycles tied to device lifecycle status. Without that, exception handling becomes permanent trust.
Why This Matters for Security Teams
Legacy medical devices are not just outdated assets. They can carry unsupported operating systems, weak authentication, hardcoded service accounts, and limited logging, while still being essential to patient care. That creates a governance problem as much as a technical one: compensating control must preserve clinical availability without pretending the original risk has disappeared. Current guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that control ownership, review, and exception handling need structure, not informal agreement.
The common mistake is treating compensating controls as a one-time approval rather than an accountable risk decision. If a device cannot be patched, then isolation, access restriction, monitoring, compensating authentication, or workflow controls need explicit owners and expiry conditions. In healthcare environments, that accountability must include the people who understand the clinical dependency, not only the people who manage the network.
Security teams often get this wrong by inheriting exceptions from procurement, vendors, or biomedical engineering without a durable review process. In practice, many security teams encounter a permanent exception only after a forgotten device has already become a routine part of care delivery.
How It Works in Practice
Accountability should be assigned to the function that can actually accept, maintain, and revisit the risk. In most environments, that means security owns the control design and risk articulation, clinical engineering owns device-specific technical reality, and operations or the clinical service line owns the service impact. The question is not who “signs off” once, but who remains responsible when the compensating control ages, fails, or becomes operationally burdensome.
A practical model is to document compensating controls as part of a formal exception record. That record should identify the device, the affected clinical workflow, the original control gap, the compensating measures in place, the monitoring requirements, and the review date. For legacy medical devices, those controls often include network segmentation, jump-host access, allowlisting, protocol restriction, enhanced logging, and strict account management. Where identity is involved, service accounts, vendor remote access, and shared administrative credentials should be treated as high-risk exceptions, not convenience shortcuts.
- Security defines the minimum control set and the monitoring expectations.
- Clinical engineering validates whether the control is safe for device operation.
- Operations or the clinical owner confirms the workflow impact and accepts residual risk.
- Risk or governance functions track review dates and escalation paths.
- Vendor input is useful, but vendor approval should not replace internal accountability.
Frameworks such as CISA medical device cybersecurity guidance and FDA medical device cybersecurity resources reinforce the need for lifecycle thinking, especially where patching is limited or device replacement is delayed. The operational goal is to make the risk visible, bounded, and reviewable rather than buried in a ticket queue.
These controls tend to break down in distributed hospital networks with multiple acquired sites because device ownership, exception approval, and asset inventory data are often split across teams that do not share a single governance process.
Common Variations and Edge Cases
Tighter compensating control governance often increases coordination overhead, requiring organisations to balance patient safety, uptime, and cyber risk against slower exception handling. That tradeoff is unavoidable when devices are embedded in critical care, imaging, or life-support workflows.
There is no universal standard for this yet on how to split accountability across security and clinical functions, but best practice is evolving toward shared ownership with a single named risk owner. For devices that are vendor-managed, the vendor can recommend control options, yet the internal organisation still owns the decision to accept residual risk. For network-isolated devices that cannot support modern agents, compensating controls may need to rely on infrastructure controls rather than endpoint tooling.
The edge case to watch is when “temporary” exceptions survive device replacement cycles. At that point, the compensating control has become the operating model, which is exactly where governance fails. Teams should also be cautious with devices that share admin credentials across many units, because a compensating control that does not address identity and access can create a false sense of safety.
Where personal health data, vendor remote support, or regulated service continuity are involved, review cadence should be more stringent and evidence should be retained for audit and incident response. NIST control families on access control, audit and accountability, and risk assessment provide a useful baseline for structuring that review process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-03 | Exception ownership is part of organisational risk management for legacy devices. |
| NIST SP 800-53 Rev 5 | RA-3 | Risk assessment supports deciding whether compensating controls are adequate. |
Assign a named risk owner and review compensating controls on a fixed cadence.
Related resources from NHI Mgmt Group
- Who is accountable when compensating controls are used instead of full separation?
- Who is accountable when AI-enabled attacks bypass legacy access controls?
- Who is accountable when passwordless controls still leave legacy access paths in place?
- Who should own the decision between replacement and compensating controls for legacy HSMs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
