What breaks when healthcare access is split between local and national identities?

Why This Matters for Security Teams

Splitting healthcare access between local and national identities creates a governance gap that is bigger than it first appears. The problem is not just duplicate administration; it is that assurance, entitlement review, and offboarding no longer happen in one place. That weakens auditability, makes access reviews harder to trust, and increases the chance that a clinician or system still has access long after the original need has passed. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a useful reminder that fragmented identity structures usually fail first at visibility.

In healthcare, that fragmentation also affects patient safety and operational resilience. Separate identity stores can lead to different authentication strength, different approval paths, and different logging standards for the same person or workload. The result is a compliance story that looks acceptable on paper but is difficult to defend when a regulator or auditor asks who approved what, when it was revoked, and whether the access was still appropriate. Current guidance from the OWASP Non-Human Identity Top 10 reinforces that inconsistent lifecycle control is a real exposure point, not an administrative nuisance. In practice, many security teams discover the gap only after a joiner-mover-leaver failure or an unexpected access review challenge has already exposed it.

How It Works in Practice

When local and national identity systems are split, organisations usually end up running two access models at once. One model may cover regional clinical systems, while the other covers national services, shared records, or external dependencies. If those identities are not linked through a clear trust and lifecycle model, the same user can hold multiple identifiers, multiple roles, and multiple revocation paths. That is where stale access, over-privilege, and inconsistent assurance emerge.

A workable design starts by defining which identity is authoritative for each access decision. In practice, teams should decide whether the local system, the national directory, or a federated identity broker is the source of truth for authentication, then map all downstream entitlements to that decision. For non-human workloads such as integration services and automation, the same logic applies: use a single workload identity pattern, short-lived credentials, and tightly scoped policy. The Ultimate Guide to NHIs is clear that secrets and service identities fail when visibility and rotation are handled inconsistently.

• Use a federated model so assurance can be checked once and consumed consistently across systems.
• Keep identity attributes synchronised so role changes, suspension, and offboarding propagate quickly.
• Log entitlement grants and revocations in a way that supports one audit trail, not two partial trails.
• Apply least privilege separately to human users, service accounts, and API-driven workflows.

Where possible, healthcare programmes should align identity governance with Zero Trust principles and strong lifecycle controls, because access should be continuously re-evaluated rather than assumed valid after initial enrolment. This guidance tends to break down in organisations with legacy EHR integrations, outsourced support desks, or manual provisioning steps because identity linkage and revocation timing become unreliable.

Common Variations and Edge Cases

Tighter identity consolidation often increases migration cost and coordination overhead, requiring organisations to balance stronger governance against clinical continuity and operational constraints. That tradeoff is especially visible when national identity assurance levels do not match local account requirements, or when certain systems cannot consume the same federation standard.

Current guidance suggests three common patterns. First, some organisations keep local identities for operational autonomy but bind them to a national source of identity for assurance and lifecycle control. Second, others use the national identity as the primary login and let local roles govern access to departmental systems. Third, a few maintain parallel identities only for truly isolated legacy platforms, but this should be treated as an exception with explicit review dates, not a default architecture.

The main edge case is emergency or break-glass access. That access may need to bypass normal approval paths, but it still needs strong logging, time limits, and post-event review. Another edge case is cross-organisational care, where contractors or partner clinicians require access across multiple trusts or regions. In those environments, fragmented identity models can be tolerated only if entitlement ownership, assurance mapping, and revocation responsibilities are written down and testable. Industry consensus is still evolving on the best identity pattern for every healthcare topology, but there is no universal standard for allowing separate identities without a single accountability model.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?