Who is accountable when a hospital contractor keeps access after the work ends?

Why This Matters for Security Teams

When a hospital contractor’s access outlives the work, the problem is not only a missed offboarding task. It becomes an accountability failure that can expose patient data, disrupt clinical operations, and weaken audit defensibility. The hospital, as the care-delivery authority, still owns access governance even when the credential was issued to a supplier. That distinction is central to non-human identity control and is reinforced in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

NHIMG research shows that 92% of organisations expose NHIs to third parties, which is why supplier access is now a routine governance concern rather than an edge case. In healthcare, that risk is amplified because third-party access often touches EHR workflows, imaging systems, integration platforms, or managed service consoles. Contracts matter, but contracts do not revoke tokens, rotate secrets, or close dormant accounts on their own. Security teams need a process that ties business approval, technical enforcement, and periodic recertification together. In practice, many security teams encounter stale contractor access only after an audit finding, a vendor change, or an incident review, rather than through intentional offboarding.

How It Works in Practice

The cleanest model is to treat contractor access as a jointly managed lifecycle with clear handoffs. The hospital should define who approves access, who provisions it, who validates ongoing need, and who performs revocation. The supplier may operate the identity, but the hospital remains responsible for ensuring the access is justified for the current engagement. That is the operational meaning of accountability in NHI governance.

In day-to-day controls, this usually means:

• Time-bound provisioning tied to a contract, work order, or service ticket.
• Role scoping that limits the contractor to named systems and explicit tasks.
• Periodic recertification by the hospital business owner, not only by the vendor.
• Immediate removal at end-of-service, contract termination, or role change.
• Logging and evidence that proves deprovisioning actually occurred.

Current guidance suggests aligning this with broader NHI lifecycle discipline, including inventory, ownership, rotation, and offboarding. NHIMG’s 52 NHI Breaches Analysis is useful here because it shows how neglected machine access often persists well past its intended use. For implementation detail, the OWASP Non-Human Identity Top 10 and the SPIFFE overview both reinforce the value of short-lived, verifiable workload identity rather than standing secrets. This is especially important when contractors access multiple systems through shared automation or remote support tooling.

These controls tend to break down when access is granted through shared admin paths, unmanaged service accounts, or vendor-operated automation that the hospital cannot directly see.

Common Variations and Edge Cases

Tighter contractor controls often increase operational overhead, requiring organisations to balance speed of delivery against stronger termination discipline. That tradeoff is real in hospitals, where urgent support, after-hours maintenance, and specialist integrations can make access look temporary even when it becomes persistent.

There is no universal standard for this yet, but current guidance suggests a few practical variations. For high-risk systems, some teams require just-in-time approval and short-lived credentials instead of standing contractor accounts. For lower-risk support, the hospital may allow longer-lived access but enforce weekly or monthly recertification. If the supplier uses its own identity provider, the hospital still needs visibility into what that identity can reach and when it was last used. If the access is embedded in automation, the control point may need to shift from user review to workload identity review and secret revocation.

Healthcare environments also need to account for emergency access and continuity of care. A break-glass exception can be justified, but it should not become a permanent workaround. The safest pattern is to couple exception handling with automatic expiry, post-use review, and named accountability. NHI Mgmt Group’s guidance on the Ultimate Guide to NHIs — Key Challenges and Risks is especially relevant when third-party access is distributed across multiple platforms and owners.

Related resources from NHI Mgmt Group

• Who is accountable when a third party keeps access after the work ends?
• What should teams do when an AI agent keeps access after a project ends?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a third-party integration keeps an NHI active after the business need ends?