Use a model that separates device restriction from user identity, then decide which actions require traceable identities and which can safely use temporary or shared sessions. In practice, that means defining roles, enforcing logout behaviour, and checking that the platform supports the required level of attribution before rollout.
Separate device lockdown from user attribution
Teams usually get into trouble when they try to use one control for two different goals. Device lockdown is about constraining what the shared endpoint can do; user tracking is about proving who performed a specific action. Keep those decisions separate, then document which workflows need named attribution, which can use a temporary session, and which simply need a supervised kiosk-style pattern.
A practical design rule is to treat the device as the controlled resource and the session as the traceable unit. That lets you harden the browser, app surface, and logout behaviour without pretending the device itself is the identity of the person using it.
How to decide when traceability is required
Not every action on a shared device needs the same level of attribution. A low-risk lookup may tolerate a transient or shared session, while approvals, changes to customer records, financial actions, or administrative operations usually need an identity that can be tied back to one person. The decision should be based on the business consequence of the action, not on the convenience of the device model.
Where accountability matters, require strong authentication at the point of action and make the audit trail reflect the actual user, not only the machine. Where attribution is less important, the control objective shifts toward preventing residue, cross-user leakage, and accidental carryover between sessions.
Build shared-device controls around session hygiene
Shared environments fail most often because the session survives longer than the user does. Automatic logout, forced re-authentication for sensitive steps, clearing of local data, and short-lived sessions are the controls that prevent the next user from inheriting the previous user's access or context. If the platform cannot enforce those behaviours reliably, reduce what the device is allowed to do rather than accepting a weak workaround.
One useful pattern is to make the device disposable from an identity perspective even if it is physically durable. That means no persistent browser state, no saved credentials, no silent reuse of elevated sessions, and no assumption that the same device equals the same person across shifts or handoffs.
Risk and Threat Considerations
shared devices create two common failure modes: unauthorized carryover of an active session and loss of attribution when multiple people use the same endpoint. Both can turn a routine workstation into a source of mistaken actions, privacy leakage, or disputed activity, especially when the platform does not separate the device trust decision from the user trust decision.
Failure mechanism: A session remains active, cached data is exposed, or the platform records only device-level activity instead of user-level activity, so the next person inherits access or the organisation cannot prove who did what.
Impact: Sensitive actions may be misattributed, privileged functions may be reused without fresh authentication, and incident investigation becomes harder because the audit trail no longer maps cleanly to a human decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Shared-device actions need attributable user identity for sensitive operations. |
| IA-5 — Authenticator Management | Session resets, logout behaviour, and temporary access depend on credential and session handling. | |
| AU-2 — Event Logging | User tracking on shared devices depends on auditable events tied to identities. | |
| Recommendation — Require named-user authentication before sensitive actions on shared devices. Enforce short-lived authenticators and revoke them at handoff. Log actions at user level so shared-device activity remains attributable. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question hinges on separating access control from device lockdown and preserving identity attribution. |
| DE.CM-01 — Networks and environments are monitored to detect potential cybersecurity events | Shared-device misuse is easier to spot when session and access activity are monitored. | |
| Recommendation — Apply identity and access controls that distinguish the user from the shared endpoint. Monitor shared-device sessions for anomalous access, handoff, and reuse patterns. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared devices require explicit access rules for who may do what on the endpoint. |
| A.8.15 — Logging | Attribution on shared devices depends on log records that identify the acting user. | |
| Recommendation — Define access rules that separate device restrictions from user privileges. Retain logs that can attribute sensitive actions to a specific user session. | ||
Practitioner Guidance
What to verify: Confirm that the platform can produce user-level audit logs, enforce logout or session timeout on handoff, and prevent remembered credentials or browser state from surviving between users. If any of those controls are inconsistent, treat the environment as higher risk than the business owner may expect.
Decision rule: If an action can change records, approve value, or expose regulated data, require a named identity and a reviewable audit trail. If the workflow is read-only or operationally low impact, a temporary or shared session may be acceptable only when the device can be reset cleanly between users.
Practitioner takeaway: Shared-device design works when attribution and lockdown are engineered as separate control objectives, because the safest device is still a bad control if it cannot prove which user performed the meaningful action.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org