When shared devices are not reset between uses, patient information, app sessions, and account state can carry forward to the next user. That undermines privacy, increases infection control concerns, and forces staff to spend time fixing devices instead of using them for care delivery. A clean handoff requires a full wipe, app reload, and verification step.
Why unreset shared devices carry risk from one patient to the next
When a device is reused without a full wipe, it becomes a continuity problem as much as a hygiene problem. Residual app state, cached logins, notifications, downloads, and local files can expose one patient’s information to the next user. In clinical settings, that also creates avoidable workflow friction because staff must troubleshoot the device before it can be trusted again.
A proper reset is not just deleting visible data. It must remove the prior user’s session state, clear locally stored identifiers, and return the device to a known baseline so the next patient does not inherit hidden access or data.
What “wipe and reconfigure” has to accomplish
A shared device should come back as if it had never been used by the prior patient. That means clearing the operating system state where needed, removing app data, forcing sign-out from any connected services, and reapplying the required configuration before the device is handed over again. If any of those steps are skipped, the device may still behave as though the previous session is active.
The practical test is simple: the next user should not be able to see prior content, resume a prior session, or inherit a logged-in app, even if the device was briefly unused. A clean handoff also needs verification, because a device can look reset while still retaining synced data or saved credentials.
This is where the device hardening baseline matters. Shared clinical devices should be treated like any other managed endpoint and reset against a consistent standard, which is why many teams align the process with CIS Benchmarks for the underlying platform. The value is not the checklist itself, but the repeatable baseline it gives operations staff.
Why the same failure also creates operational and access-control issues
Leaving a shared device in an unknown state creates more than privacy exposure. It can also leave behind active authentication state, app permissions, or stored tokens that let the next person act under the prior user’s context. In practice, that means care staff may inherit the wrong account, the wrong chart view, or the wrong app permissions, which is a classic access-control failure at the point of reuse.
Security standards for endpoints and authenticating systems consistently emphasise baseline configuration, identification, and access control for exactly this reason. A device that is not returned to a known state cannot be trusted as a shared clinical tool, even if the hardware itself is functioning normally.
That is also why reset procedures should be paired with credential and session hygiene. If the device or app uses shared authentication material, the organisation should review the session and credential lifecycle rather than assume that closing the app is enough. For general control coverage, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful anchor for access control, configuration management, and audit expectations.
Risk and Threat Considerations
shared devices that are not wiped between patients create a predictable exposure pattern: the next user may see prior patient information, and a malicious or careless user may be able to act in someone else’s session. In a healthcare context, the harm is not limited to confidentiality. It can also affect operational trust, device availability, and the integrity of patient-facing workflows.
Failure mechanism: Residual application state, cached credentials, open sessions, and local data survive the handoff, so the device continues to trust the previous user’s context instead of starting fresh.
Impact: Patient data leakage, accidental record access, session confusion, and additional recovery work for staff become more likely, especially when the device is reused many times per shift.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Shared devices must be inventoried and managed before safe reissue. |
| Recommendation — Track shared devices and verify each unit is returned to a known managed state before reuse. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Residual sessions and stored credentials on shared devices are a credential lifecycle risk. |
| CM-2 — Baseline Configuration | A wiped device needs a restored baseline to prevent leftover patient state. | |
| Recommendation — Revoke or reset authenticators and tokens before handing the device to the next user. Reapply a known baseline configuration after each wipe and validate it before reuse. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Shared device reconfiguration depends on controlled, repeatable baseline restoration. |
| Recommendation — Define and enforce a configuration reset standard for shared patient devices. | ||
| OWASP ASVS | V7 — Session Management | Patient reuse risk includes residual app sessions and session state on the device. |
| Recommendation — Ensure sessions are fully terminated and cannot resume for the next user. | ||
Practitioner Guidance
What to verify: Treat the handoff as incomplete until the device has been wiped, reimaged or reprofiled as required, apps have been relaunched in a clean state, and a human has confirmed that no previous session or patient data is visible. The verification step matters because a partial reset can look successful while still leaving hidden state behind.
Common mistake: Relying on app logout alone. If the device retains local cache, downloaded documents, push notifications, or saved tokens, the next patient may still inherit access or data even though the app appears closed.
Practitioner takeaway: For shared clinical devices, the real control is not the reset action by itself, but the combination of wipe, reconfiguration, and explicit validation before the device returns to circulation.
Related resources from NHI Mgmt Group
- What happens when shared mobile devices are not depersonalised between users?
- What breaks when shared mobile devices stay signed in between users?
- How should healthcare IT teams decide between shared and 1-to-1 mobile devices for clinical workflows?
- What is the difference between shared mobile devices and 1-to-1 devices in clinical care?