Look for clean session handoff, reliable logout behaviour, and evidence that the next user never inherits the previous session’s access state. If users can move between devices or accounts without strong re-authentication and audit trails, the control is not working as intended. In shared environments, residual session access is the failure signal.
Why This Matters for Security Teams
Shared-device access control only matter if the next user starts from a clean state. In practice, the control is not “login succeeded” but “previous session state was fully removed.” That includes browser cookies, cached tokens, local storage, app sessions, and any device-level authentication artifacts that can survive handoff. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a useful reminder that invisible identity state is where control failures hide.
Security teams often assume logout is enough, but shared endpoints are where residual access, weak session termination, and forgotten privilege state show up first. This is especially relevant in call centres, healthcare stations, kiosks, hot-desking, and retail terminals where one user’s context can bleed into another’s. OWASP’s Non-Human Identity Top 10 reinforces the broader lesson: identity controls are only effective when credential lifecycle and session lifecycle are both verified. In practice, many security teams discover shared-device weaknesses only after an audit or incident reveals that the “logged out” session was still usable by the next person.
How It Works in Practice
Testing shared-device controls means validating the full handoff path, not just the sign-out button. The best practice is to treat each user switch as a fresh trust decision. That usually requires re-authentication, session revocation, and confirmation that device-local caches cannot restore access. For environments with regulated data, session management expectations often align with PCI DSS v4.0, but current guidance suggests the exact technical pattern can vary by platform and application stack.
Operational checks should include:
- Confirming logout invalidates server-side sessions, not just the browser view.
- Verifying tokens, cookies, and app caches are removed or expire immediately after handoff.
- Testing whether a new user can reach prior inboxes, dashboards, shared files, or admin panels without fresh authentication.
- Reviewing audit logs to ensure the second user is recorded as a new session, not a continuation of the first.
- Checking idle timeout, screen lock, and forced re-authentication behaviour on the device itself.
For higher-risk workflows, session isolation should be paired with strong identity proofing and step-up controls when context changes. The 52 NHI Breaches Analysis shows how often identity state is abused once trust is misplaced, even when the initial access path looks legitimate. Controls tend to break down in environments that rely on a shared browser profile or persistent desktop session because the application cannot reliably distinguish a logged-out user from the next person on the same device.
Common Variations and Edge Cases
Tighter session isolation often increases user friction and support overhead, so organisations need to balance security against operational speed. That tradeoff is real in environments with rapid turnover, clinical workflows, or frontline devices where repeated prompts can slow work. Where consensus is still evolving, current guidance suggests prioritising short-lived sessions and clean revocation over convenience, but not every application can enforce this uniformly.
Some edge cases deserve special attention. Shared tablets may appear secure because the app auto-resets, yet background tokens can still persist in the browser or OS account. Single sign-on can also mask failure if the identity provider session remains active after the local app is closed. In kiosk-style deployments, the safest pattern is often a dedicated locked-down profile with enforced timeout, application-level logout verification, and periodic re-authentication for sensitive actions.
For teams validating the control, the question is not whether access was granted once. It is whether the next person can inherit any usable state at all. That is why a control can look healthy in normal use and still fail under rapid user switching, offline operation, or incomplete app integration with the central identity layer.
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 NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Session state and credential lifecycle failures are central to shared-device access. |
| NIST CSF 2.0 | PR.AC-7 | Shared-device checks depend on strong session management and re-authentication. |
| NIST SP 800-63 | AAL2 | Re-authentication strength matters when devices are reused by different users. |
Verify logout, token invalidation, and session expiry together before declaring shared-device access safe.
