Shared use of work devices breaks accountability and increases the chance of accidental disclosure, deletion, or unauthorised access to sensitive information. Children, family members, or other users may open work files, send messages, install software, or change settings without understanding the consequences. In practice, the device stops being a controlled business endpoint and becomes an unreliable trust boundary.
Why shared work devices break the trust model
A work device is only reliable when the organisation can assume a known user, a known configuration, and a known chain of custody. Once multiple people use the same laptop, tablet, or phone, those assumptions fail. Session state, cached credentials, browser history, local files, and notifications can all become visible to the next person, which makes the endpoint much harder to treat as a controlled business asset.
The practical effect is not just inconvenience. Shared use blurs who is responsible for actions taken on the device, and that weakens both prevention and investigation. If a file is changed, a message is sent, or a setting is altered, it becomes harder to tell whether the action came from the employee, a family member, or someone else who had access.
When the device is part of an environment that depends on identity controls, that loss of clarity matters. Strong endpoint hygiene, user separation, and device enrollment are the difference between a managed endpoint and an ambiguous trust boundary. Shared endpoints also undermine visibility into what data was accessed, which can make incident response and compliance review much less reliable. For broader context on endpoint hardening and control expectations, see CIS Benchmarks and NIST Cybersecurity Framework 2.0.
What can go wrong in day-to-day use
Most failures on shared work devices are mundane, which is why they are so common. Another user may open business email, accidentally disclose sensitive information, delete files, approve prompts without understanding them, or install software that changes the security posture of the endpoint. Even well-intentioned use can create exposure if personal browsing, auto-fill, or stored chats mix with work activity.
The risk increases when users are not equally security-aware. Children or family members may click links, re-open notifications, or change settings that disable safeguards. Co-workers sharing a single kiosk or shift device can also inherit one another’s browser sessions, downloads, or authenticated apps if logout is incomplete. In practice, the endpoint becomes only as safe as the least careful person who can touch it.
That is why shared-use scenarios should be treated as control exceptions, not normal operating mode. If the business process truly requires a pool device, the organisation should expect shorter session lifetimes, tighter local storage limits, stronger logout behaviour, and cleaner separation between users. Shared-device design is a discipline of reducing leftover state, not just adding a password screen.
One useful benchmark for the broader identity and access risk created by uncontrolled use of credentials and sessions is NHIMG’s Ultimate Guide to NHIs, which notes that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage.
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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Shared devices need hardened, repeatable endpoint settings to reduce leftover state and misuse. |
| CIS 5 — Account Management | Shared use makes account ownership and session separation central to accountability. | |
| Recommendation — Enforce standard device configurations and remove unnecessary local persistence on shared endpoints. Assign unique user accounts and prevent shared credentials on work devices. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | The topic hinges on controlled access, user separation, and preserving endpoint trust boundaries. |
| PR.PT — Protective Technology | Shared endpoints require technical controls that limit residual access and exposure. | |
| DE.CM — Continuous Monitoring | Shared-device misuse is harder to detect without endpoint visibility and logging. | |
| Recommendation — Apply identity and access controls so each user session is distinct and attributable. Use endpoint safeguards that restrict leftover data, auto-access, and unsafe persistence. Monitor shared endpoints for anomalous logins, settings changes, and data access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Shared device use can expose stored credentials, tokens, and sessions that enable unauthorized access. |
| NHI-04 — Identity Lifecycle and Offboarding | Shared endpoints need reliable revocation and cleanup between users to prevent residual access. | |
| Recommendation — Remove stored secrets and session material from devices that multiple people can use. Ensure every user handoff clears access, sessions, and locally cached identity material. | ||
Practitioner Guidance
What to prioritise: Treat the first question as whether the device needs to be shared at all. If one person can be assigned ownership, that is usually the safer design. Shared devices should be reserved for cases where the business process genuinely requires them, such as shift work, kiosks, or front-line operations.
What to verify: Make sure the device cannot retain another user’s session, local files, notifications, or browser state in a way that survives handoff. Verify logout behaviour, profile separation, and what remains accessible after the previous user leaves. If you cannot confidently describe the leftover state, the control is not strong enough.
Common mistake: Assuming that a lock screen is the same as user separation. A locked shared device can still carry cached access, synced data, notifications, and signed-in applications. The security question is not whether the screen is locked, but whether the next person can inherit meaningful access or information.
Practitioner takeaway: The real decision is whether the endpoint can preserve accountability and data separation between users. If it cannot, treat the device as untrusted for sensitive work and redesign the operating model rather than trying to compensate with a single control.
Related resources from NHI Mgmt Group
- Should organisations use the same process for onboarding people and machine identities?
- Should organisations let AI agents use the same login flow as employees?
- What breaks when multiple people use the same shared account password?
- What happens when organisations let AI absorb too much analytical work?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
