Should hospitals treat shared mobile devices as an IAM priority or a device management issue?

Why shared mobile devices are an identity problem first

On a shared device, the security question is not just whether the tablet or phone is hardened. It is whether the right person is authenticated at the right time, whether the prior session is truly ended, and whether the next user inherits any cached access. For hospitals, that makes shared-device governance an IAM and identity provider problem as much as a device problem.

Shared devices compress multiple users, shifts, and clinical roles into one endpoint. If identity state is not reset cleanly between users, the device becomes a shortcut around intended access boundaries. The hardware can be compliant while the access path is still wrong.

That is why the practical unit of control is not the device alone, but the identity-session pair. Hospitals need to know who is on the device, what applications they can reach, and how quickly that access can be removed when a task, shift, or clinical context changes. A device-only model can lock the screen; it cannot reliably answer who should be there next.

Where device management helps, and where it stops

mobile device management still matters. It can enforce encryption, screen lock, app allowlists, remote wipe, and configuration baselines. It also reduces the chance that a lost or shared endpoint becomes a general-purpose attack surface. But those controls protect the endpoint, not the identity decision.

For hospitals, the boundary becomes clear when a control affects the hardware, but not authentication, role assignment, or session re-association. The same device can be very well managed and still be unsafe if a previous user remains signed in to EHR, messaging, imaging, or clinical workflow tools.

Shared-device programs work best when MDM and IAM are paired intentionally. One controls device posture, the other controls access lifecycle. If either side is treated as optional, the hospital ends up with inconsistent enforcement, especially across shift changes and break-glass scenarios.

What hospitals should govern together

Hospitals should design shared-device access around login, logout, reassignment, and revocation, not just enrollment and patching. The critical questions are whether the device can prove the current user, whether sessions expire quickly enough, and whether application tokens or cached credentials survive handoff.

The strongest pattern is to connect device policy to identity policy so that access is bounded by role, location, and time. Lifecycle processes matter here because stale access on a shared endpoint is the same operational failure mode as stale access elsewhere: provisioning without timely deprovisioning creates residual privilege.

Where hospitals support clinical mobility, they should also expect higher exposure from reused credentials, shared accounts, and lingering sessions. The issue is not just convenience. It is whether access can be attributed, limited, and ended in a way that still supports care delivery.

Risk and Threat Considerations

shared mobile device create a predictable exposure pattern: the prior user’s authenticated state, cached tokens, or open clinical applications can become the next user’s entry point. In a hospital, that can lead to unauthorized chart access, mistaken actions under the wrong identity, or broader lateral movement if the device is also a gateway to internal systems.

Failure mechanism: Weak handoff controls, persistent sessions, and reused credentials allow one user’s access context to survive shift change, which defeats the intended separation between users even when the device itself is compliant.

Impact: Patient-data exposure, inaccurate audit trails, inappropriate action attribution, and, in the worst case, abuse of trusted clinical access paths from a device that appears legitimate.

Practitioner Guidance

What to prioritise: Treat session termination and user re-authentication as the first design requirement for any shared medical device. If the next clinician can inherit access without proving identity again, the control model is too weak even if the device is fully encrypted and supervised.

What to verify: Confirm that logout really revokes application access, that tokens and cached credentials do not persist across handoff, and that the device can rebind the right user quickly enough for clinical workflow. For shared-device programs, the test is not whether the screen locks, but whether the next user starts from a clean identity state.

Practitioner takeaway: In hospitals, shared mobile devices should be governed as a joint IAM and device-management problem, but identity controls must lead because the main failure is not hardware compromise, it is access continuity between users.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• How should hospitals govern shared mobile device access across clinical shifts?
• Why do shared mobile devices create IAM risk in healthcare?
• Why do shared mobile devices create governance problems for IAM teams?