When devices are handed off without depersonalization and reauthentication, the next user may inherit access, session state, or sensitive data that belonged to someone else. That breaks separation between users and creates a direct path to unauthorized viewing, accidental data disclosure, and accountability gaps. In shared environments, each exchange must be treated as a security boundary.
What changes when a shared device is handed off without depersonalization?
The security boundary is not the hardware itself, it is the user state left behind on the device. If a shared tablet or phone is passed to another person without clearing credentials, cached sessions, local app state, or autofill data, the next user may act inside the previous user’s context. That can expose content, permit unintended actions, and make later review ambiguous.
Shared devices are especially sensitive because mobile operating systems are designed to preserve continuity for convenience. That continuity becomes a liability when the device is used as a workstation, kiosk, or front-line business tool. The practical question is not whether the device still works, but whether any identity-bearing state still does.
A useful way to think about this is to treat every handoff as a control point. If the device is not explicitly depersonalized, the session boundary may remain open even though the physical device changed hands. That is why shared-device procedures need to address sign-out, local data removal, app-level cache, and any trusted credential material that can survive a normal app close or screen lock.
Why reauthentication matters after every handoff
Reauthentication forces the new user to establish a fresh, attributable session rather than inheriting a previous one. That matters when apps rely on bearer sessions, remembered logins, or device trust. Without reauthentication, a person can appear authenticated simply because the device still holds valid state, not because the new user proved who they are.
This is the same basic control logic behind session security and access boundary enforcement: the session should belong to one user, for one period, under one accountability trail. When a shared device skips that step, the system may no longer know who is operating it, which weakens access decisions, auditing, and incident investigation. For practical guidance on session handling, the Token and Session Security Guide covers how lingering tokens and session state are abused.
Reauthentication also reduces the risk that a device-level unlock is mistaken for application-level authorization. A locked phone or tablet may protect the screen, but it does not always reset the app session, browser cookies, or offline data. In shared environments, that distinction is critical because the person holding the device is not automatically the person entitled to the previous user’s data or actions.
What failure modes are most common in shared mobile use?
The most common failure is residual access, where a still-valid token, remembered session, or app cache grants the next user unintended entry. A second failure is data persistence, where downloaded files, previews, notification content, or synced records remain locally visible after the handoff. A third is attribution failure, where actions taken from the device cannot be confidently tied to the correct person.
Credential and session material are the highest-risk leftovers because they can convert a simple handoff into unauthorized access. This is why mobile sharing controls should be designed around credential removal, session invalidation, and short-lived access rather than around the assumption that screen locking is enough. Where the device is used for privileged or business-sensitive tasks, the OWASP Non-Human Identity Top 10 is not the direct model here, but its emphasis on secret leakage, overprivilege, and lifecycle discipline reinforces the same control principle for any bearer access material.
Shared-device failure can also come from convenience features that behave like hidden persistence, such as password managers, browser autofill, synced messaging previews, or “keep me signed in” options. If those features are enabled on a device that rotates between users, the risk is not just accidental disclosure. It is that the device quietly becomes a bridge between identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Residual credentials and session material on shared phones can expose prior-user access. |
| NHI-01 — Improper Offboarding | Handoffs without cleanup are a lifecycle offboarding failure for shared device access. | |
| NHI-07 — Long-Lived Secrets | Remembered logins and persistent tokens extend access across users on shared devices. | |
| Recommendation — Remove cached secrets and invalidate sessions at every device handoff. Require a clean offboarding step before the device changes users. Shorten token lifetimes and avoid persistent credentials on shared devices. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential removal and reauthentication depend on managing authenticators and their lifecycle. |
| AC-12 — Session Termination | Shared-device handoffs require session end to prevent inherited access. | |
| IA-2 — Identification and Authentication (Organizational Users) | Reauthentication is needed so each user proves identity on a shared device. | |
| Recommendation — Revoke or clear authenticators before reusing the device. Terminate active sessions before releasing the device to another user. Require each user to authenticate again after the handoff. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure Authentication | Shared mobile devices need fresh authentication after handoff to prevent inherited access. |
| Recommendation — Enforce fresh authentication whenever the device changes users. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Shared-device access must be removed or reset between users to avoid unintended access. |
| Recommendation — Reset access state before the device is reused. | ||
Practitioner Guidance
What to verify: Before a shared mobile device changes hands, verify that the previous user’s active sessions are closed, local app data is cleared where needed, and any saved credentials or autofill artifacts are removed. If the app cannot reliably separate one user from the next, it should not be used in a shared workflow.
Decision rule: If the device can access email, messaging, files, or internal business apps, treat reauthentication as mandatory on every handoff. If the device is only being used for low-risk kiosk functions, you still need a controlled logout or reset path, because convenience features often leave more state behind than teams expect.
What good looks like: The next person receives a device that starts from a known, clean state, with no prior-user content visible, no surviving session continuity, and no ambiguity about who is responsible for the next transaction or view.
Practitioner takeaway: Shared mobility only stays safe when the handoff itself is treated as a boundary event, not a convenience step; if you cannot prove the previous user’s state is gone, you should assume the next user can inherit it.
Related resources from NHI Mgmt Group
- What happens when shared mobile devices are deployed without a plan for interoperability and long-term adoption?
- What happens when shared mobile devices are not depersonalised between users?
- How should healthcare organisations secure shared mobile devices without slowing clinicians down?
- What breaks when shared mobile devices stay signed in between users?