How should healthcare teams design patient authentication for shared devices?

They should assume that more than one person may use the same phone, tablet, or browser. That means avoiding long-lived session trust, making account recovery explicit, and preventing one user’s authentication state from carrying into another user’s care journey. Shared-device reality should shape the identity model, not be treated as an exception.

Why This Matters for Security Teams

Shared devices in healthcare create a deceptively simple authentication problem: a clinician, patient, caregiver, or family member may all use the same phone, tablet, kiosk, or browser within a short period of time. If identity state is not reset cleanly, one person can inherit another person’s session, records access, or recovery path. That turns authentication into a patient safety issue, not just an access-control issue. Current guidance from the NIST Cybersecurity Framework 2.0 points teams toward governance, access control, and recovery discipline, but healthcare workflows add a stronger need for explicit device re-authentication and context-sensitive sign-out. NHI Management Group’s Ultimate Guide to NHIs shows how often identity and secret handling fail when lifecycle controls are weak, and the same pattern appears in shared-device care journeys. In practice, many security teams encounter account bleed-through only after a patient opens the wrong chart or a prior user’s session remains active at the point of care.

Shared-device authentication should be designed around the assumption that the device is not trusted to preserve user separation on its own. That means the identity layer must re-establish who is present, what role they hold, and whether the session is still appropriate for the current care moment. For healthcare teams, this is especially important in waiting rooms, bedside tablets, telehealth stations, and kiosk flows where one browser profile may serve multiple people in a shift.

Practical designs usually combine short session lifetimes, explicit re-authentication at sensitive actions, and fast session termination when a user completes care tasks. Where possible, teams should prefer device-agnostic identity checks that do not rely on a remembered browser state. For example, a patient portal should require a fresh step-up check before medication, billing, or test-result access, even if the device was recently used by the same account. The control objective is not convenience at all costs, but clean separation of identity state between users.

This is also where workload identity concepts offer a useful mental model. Just as NHI programs avoid assuming a long-lived credential should stay valid forever, shared-device patient authentication should avoid long-lived trust in the device session. If the workflow includes token issuance, recovery links, or mobile handoff, those artifacts should be short-lived, single-purpose, and revoked when the task is complete. Standards bodies are moving in this direction, but there is no universal standard for every healthcare shared-device pattern yet. Teams often map the journey using policy-based access rules, then enforce the edge cases with explicit logout, idle timeout, and re-verification triggers. These controls tend to break down when the same tablet is used for both patient self-service and staff workflows because session context becomes ambiguous and role separation weakens.

How It Works in Practice

A workable pattern starts with session design, not password policy. The device should never be treated as the unit of trust. Instead, the authentication flow should bind the current user to a short-lived session and revoke that binding as soon as the task ends or the user is inactive. For shared devices, that usually means a combination of short idle timeouts, explicit logout, and step-up authentication before any sensitive action.

• Use fresh authentication for account recovery, prescription changes, record export, and billing changes.
• Clear browser state, cached tokens, and app sessions when a user completes the workflow.
• Require a visible identity reset at handoff so the next user does not inherit the prior session.
• Separate patient, caregiver, and staff journeys so their authorization rules do not overlap by accident.

Implementation should also account for authentication recovery. Shared-device environments often fail when password reset or magic-link flows silently assume a personal device. Instead, recovery should be explicit, time limited, and verified through a channel that belongs to the user, not the kiosk. NIST guidance on digital identity reinforces the need for strong proofing and recovery discipline, and the operational lesson aligns with NHI lifecycle control: short-lived trust is safer than durable convenience. Where healthcare teams use federated identity or single sign-on, the logout path must terminate both the application session and the identity provider session, or the next user may inherit access unintentionally. The Ultimate Guide to NHIs is relevant here because it highlights how lifecycle failures and overlong trust windows lead to exposure.

Policy should be evaluated at the moment of access, not only at login. That lets the system decide whether the current action, device state, location, or elapsed time warrants re-authentication. This is especially important in telehealth and bedside workflows where the device is shared, but the patient context changes quickly. These controls tend to break down in environments where a single kiosk must support anonymous access, authenticated patient access, and staff override flows without a clean application boundary because the session model becomes too ambiguous to enforce reliably.

Common Variations and Edge Cases

Tighter authentication often increases friction, requiring organisations to balance patient convenience against the risk of session leakage. That tradeoff becomes visible in emergency departments, outpatient waiting rooms, and home-health setups where users may be distressed, time constrained, or assisted by another person.

Some teams try to reduce friction by letting a device “remember” a patient for longer, but that is usually the wrong compromise for shared hardware. Best practice is evolving toward shorter trust windows, not longer ones. A good exception is a low-risk informational kiosk that never exposes personal health data and resets after every interaction; in that case, the identity burden can be lighter. But once the workflow includes lab results, refill requests, records access, or identity recovery, the device must behave like a transient endpoint, not a personal device.

Healthcare also needs careful handling of proxies and caregivers. A family member may help a patient log in, but the system should still preserve who is acting and why. When that distinction matters, use delegated access or documented proxy roles rather than sharing credentials. That is where current guidance suggests separating authentication from authorization more explicitly, because the wrong person may be physically present while the right account holder is absent. In practice, the hardest failures happen when a “helpful” shared login is introduced to speed up care and then becomes the default access path for everyone.

Related resources from NHI Mgmt Group

• How should security teams handle authentication for shared retail devices?
• How should teams assess clustered applications that share authentication state?
• How should teams secure non-human identities across cloud and SaaS?
• How should security teams decide whether JIT access is safe for non-human identities?