How should NHS hubs govern access across staff, patients, and connected devices?

How to separate access across staff, patients, and connected devices

An NHS hub should not treat every user or device as equivalent just because they connect to the same environment. Workforce users, patients, and connected devices need distinct trust assumptions, distinct authentication methods, and distinct routes to the systems they can reach. That prevents convenience features from bleeding into clinical access and keeps the access model understandable when incidents, audits, or exceptions arise.

The most important design choice is to make the access model population-aware. Staff need governed workforce access, patients need tightly scoped self-service access, and connected devices need machine-oriented trust and lifecycle controls. When those paths are separated cleanly, you can apply different checks for identity, posture, and session risk without forcing one control set to serve all three groups badly.

This is also why the hub should avoid a single flat network identity layer. A permissive shared access layer tends to turn local convenience into systemic exposure, because a compromise in one population can be converted into lateral movement or over-broad visibility in another. Separate access paths make it easier to limit what each population can do, where it can go, and what evidence you need before granting more access.

Why access control, device posture, and routing must be designed together

Access control alone is not enough if the hub does not also know what kind of device is connecting and which service path it is trying to use. A clinician on a managed laptop, a patient on a personal phone, and a connected medical device each create different risk conditions, so the routing decision should be aligned to both who is connecting and what is connecting. That is the practical way to keep convenience functions available without weakening clinical systems.

Device posture matters because not every access request should be trusted at the same level. A managed device with current updates and strong identity controls may be suitable for broader workforce access, while a patient endpoint or connected device may need narrower, purpose-built access. The hub should use those differences to steer sessions into the right service zone rather than hoping a single authentication event can safely cover every use case.

Where hubs fail, they usually fail by allowing an identity decision to become a network decision. If patient services, workforce workflows, and device telemetry all land in the same permissive segment, access policy becomes harder to explain and easier to misconfigure. A better pattern is to bind each access path to a clear business purpose, then let the routing layer enforce that purpose consistently.

What good governance looks like for a shared NHS trust environment

Good governance starts with explicit ownership of each access population and each connected device class. Staff access should be managed as workforce access, patient access as consumer-facing access, and device access as a managed trust relationship with its own onboarding, review, and revocation rules. That separation makes it easier to assign accountability when a control gap or service failure appears.

For connected devices, lifecycle discipline is especially important. A device should not stay trusted just because it was once approved, and access should not survive a failed posture check, a lost management relationship, or a change in clinical role. The same principle applies to patients and staff, but the signals and remediation paths differ, so the hub needs policy branches rather than one catch-all rule.

Strong access governance also means the hub must support least privilege by design. If a patient journey only needs booking or results visibility, it should not share the same access route as clinical administration or device management. If a device only needs to publish telemetry, it should not inherit human-style session privileges. The policy should reflect the smallest practical trust boundary that still supports the service.

Risk and Threat Considerations

A shared NHS hub becomes risky when convenience is allowed to outrun segmentation. The main exposure is not just unauthorised access, but accidental expansion of trust, where one account, one device class, or one routed service can reach more than intended. That creates a larger blast radius if credentials are stolen, a device is compromised, or an access rule is misapplied.

Failure mechanism: Flat or weakly separated access paths let an attacker or misconfiguration move from a low-trust population into higher-value clinical or administrative services, especially when device trust and user trust are treated as interchangeable.

Impact: The result can be over-broad access, lateral movement, service misuse, and harder incident containment across patient, workforce, and connected-device functions.

Practitioner Guidance

What to prioritise: Define the three access populations first, then map each one to its own authentication, device trust, and service-routing policy. If you cannot explain why two populations share the same access path, they probably should not.

What to verify: Confirm that a patient session cannot inherit workforce reach, that a connected device cannot behave like a user session, and that revocation actually removes access at the routing layer, not just in the directory.

What good looks like: The hub should show different control evidence for different trust classes, with clear approval, posture, and logging paths for staff, patients, and devices. If the control story is the same for all three, the design is too coarse.

Practitioner takeaway: The safest hub design is not the one with the fewest controls, but the one that keeps each population in its own trust lane while preserving a simple and auditable service experience.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern access when users move across devices and cloud apps?
• How should teams govern access across Active Directory and connected applications?