Accountability sits with the manufacturer for ensuring cybersecurity does not compromise clinical performance, but healthcare operators also need ownership for deployment, monitoring, and maintenance. The practical question is not who caused the weakness alone, but who controls the patch path, the risk decision, and the response when patient harm becomes plausible.
Why This Matters for Security Teams
When a medical device cyber issue can affect patient safety, accountability is not limited to the team that wrote the vulnerable code. It also includes the manufacturer’s security engineering, clinical risk management, and post-market response, plus the healthcare operator’s deployment, monitoring, and maintenance decisions. That shared reality is why NHI and secrets governance matter so much in connected care environments.
NHIs are often the hidden path from a software flaw to a clinical impact. The NHIMG Ultimate Guide to NHIs — Why NHI Security Matters Now shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is especially relevant when medical devices rely on backend services, telemetry pipelines, or remote update channels. For broader incident context, see The 52 NHI breaches Report.
For security teams, the practical issue is not just whether a flaw exists, but whether the device can be patched, isolated, monitored, or safely compensated without interrupting care. In practice, many security teams encounter patient safety exposure only after an adversary, failed update, or expired credential has already turned a technical weakness into a clinical risk.
How Accountability Works in Practice
Accountability is usually distributed across the product lifecycle, but it must be explicit. The manufacturer is accountable for secure design, validation, vulnerability handling, and communicating risk. The healthcare operator is accountable for configuration, network segmentation, access control, patch adoption, and compensating controls. In regulated environments, current guidance suggests treating device cyber risk as part of patient safety risk, not a separate IT issue.
That means the question is not only who discovered the issue, but who controls the patch path, who can disable a risky service account, and who can decide whether a degraded mode is acceptable. Where devices depend on secrets, API keys, or service accounts, the operational burden often shifts to NHI lifecycle controls: inventory, rotation, revocation, and monitoring. NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification, which is a serious problem when a device update window is short.
- Manufacturers should document the threat model, dependency map, and safe update procedure.
- Operators should track device identities, service accounts, certificates, and remote support access.
- Both sides should define escalation paths for cyber events that could affect therapy, diagnosis, or monitoring.
- Both sides should test rollback, isolation, and emergency patch workflows before an incident.
For implementation context, CISA’s cyber threat advisories remain useful for operational response planning, while the NHIMG Ultimate Guide to NHIs — Key Challenges and Risks is a strong reference for service-account and secrets risk in complex environments. These controls tend to break down when devices are managed through shared service accounts, vendor VPNs, or long-lived credentials because attribution and emergency revocation become too slow for clinical timelines.
Where the Standard Answer Breaks Down
Tighter control over medical device access often increases operational overhead, requiring organisations to balance patient safety against uptime, vendor support, and clinical workflow constraints. That tradeoff is real, especially where devices cannot tolerate frequent restarts or where patch approval is tied to validation cycles.
There is no universal standard for this yet, but best practice is evolving toward joint accountability with clear decision rights. A manufacturer may own the vulnerability and remediation plan, while the operator owns the local risk acceptance decision and the controls that keep the device safe until remediation lands. If the device uses third-party telemetry or remote support, the vendor’s and operator’s non-human identities can both become part of the safety case.
One common edge case is legacy equipment that cannot support modern authentication or timely patching. Another is managed service integration, where a third party holds the credentials that can change device state. In those cases, current guidance suggests compensating controls such as segmentation, strict secret rotation, short-lived access, and continuous monitoring. The key lesson from 52 NHI Breaches Analysis is that weak identity hygiene often turns a manageable flaw into a broader safety event long before formal accountability is assigned.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Medical device risk often hinges on weak secret rotation and revocation. |
| NIST CSF 2.0 | RS.RP-1 | Patient-safety cyber events require a rehearsed response path and ownership. |
| NIST AI RMF | AI RMF governance is relevant where automated clinical systems affect safety decisions. |
Inventory device secrets and enforce short-lived, revocable credentials with tested rotation.
