Why do stale service accounts and dormant device identities increase risk in healthcare environments?

Why This Matters for Security Teams

Stale service accounts and dormant device identities are dangerous because they behave like legitimate access long after the business need has disappeared. In healthcare, that matters across EHRs, imaging platforms, billing systems, lab interfaces, and connected devices that may still trust an identity even when the original owner, vendor, or asset is gone. NIST’s Cybersecurity Framework 2.0 treats identity governance as a core risk function, not an optional hygiene task.

The practical issue is not just accumulation. Dormant identities often retain broad privileges, shared secrets, or API access that were never designed for offboarding. Once a nurse, contractor, or medical device retires, the account may still connect to file shares, middleware, backup jobs, or clinical integrations. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly why dormant access survives routine reviews. In practice, many security teams discover these paths only after a ransomware event, a vendor exit, or a failed audit rather than through deliberate lifecycle control.

How It Works in Practice

Healthcare environments tend to accumulate identities faster than they retire them. A service account may be created for a PACS integration, a device firmware updater, or an HL7 interface and then left untouched for years. A device identity may persist after decommissioning because the asset record, certificate, or secret was never fully revoked. Over time, these accounts become attractive reuse targets because they are trusted, seldom monitored, and often exempt from the normal joiner-mover-leaver process.

Good practice starts with inventory and lifecycle ownership. Teams should identify where non-human identities exist, who owns them, what they can reach, and when they were last used. That should include local accounts on endpoints, directory-based service accounts, device certificates, API keys, and embedded credentials in scripts or clinical automation. NHIMG’s Top 10 NHI Issues and the NHIMG 2024 ESG Report: Managing Non-Human Identities both show that weak visibility and poor rotation are common failure points.

A practical control stack usually includes:

• Ownership mapping for every service account and device identity.
• Time-bound secrets with rotation tied to use, not calendar convenience.
• Automated disablement when a device is retired, a vendor contract ends, or a service is replaced.
• Periodic entitlement review for accounts that do not have a human approver.
• Logging and alerting on dormant but still-valid credentials.

NIST SP 800-53 Rev. 5 also reinforces the need for account management, least privilege, and auditability in environments handling sensitive data. These controls break down when healthcare systems depend on legacy interfaces that cannot tolerate credential changes without coordinated downtime and vendor support.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance security gains against clinical uptime, vendor dependencies, and legacy system constraints. That tradeoff is real in hospitals where an account may support a life-critical device, a third-party maintenance tool, or a 24/7 interface that cannot simply be disabled without planning.

Best practice is evolving for these edge cases. Some environments still rely on shared service accounts because the application cannot support per-workload identity, but that should be treated as a temporary exception with compensating controls, not a stable design. Segment the account, limit its scope, store its secret in a controlled system, and require explicit review after every vendor change or device replacement. Where possible, shift toward unique workload identities and short-lived credentials so access is tied to the current task rather than a permanent secret.

There is also a distinction between “inactive” and “safe to remove.” A dormant identity may be unused today but still linked to a backup job, a device service window, or a delayed clinical workflow. Removal decisions should be validated against system dependency maps, not just last-login data. NHIMG’s 52 NHI Breaches Analysis shows how often identity misuse becomes an entry point once attackers find these forgotten trust relationships.

Related resources from NHI Mgmt Group

• Why do dormant accounts and over-permissioned identities increase compliance risk in regulated environments?
• Why do stale service identities increase risk in cloud environments?
• Why do service accounts and vendor identities increase risk in clinical environments?
• Why do deprovisioned and inactive accounts increase security risk in SaaS environments?