How should teams decide between locking and logging out devices?

Use locking when a user needs quick re-entry to locally stored data and the device remains under trusted control. Use logging out when the endpoint should no longer keep any retrievable copy of the vault. The key decision is whether local persistence is acceptable for that user and device class.

How to decide whether lock or log out

The decision turns on what you need to preserve on the device. Locking keeps the session boundary intact, so it is appropriate when the user is expected to return soon and the endpoint is still trusted. Logging out breaks that local continuity, which is safer when the device should no longer retain access to data, sessions, or cached vault material.

What changes operationally between a lock and a logout

Lock is a continuity control, not a cleanup control. It protects the active session from casual use while preserving the state the user left behind. Logout is a reset of the authenticated context, which is the better choice when you want to end any retrievable local access path and reduce the chance that another person, app, or later session can resume from stored state.

Teams should treat the choice as a trust question about the endpoint, not just a convenience question for the user. If the device is personally controlled, short-lived, and likely to be re-opened by the same person, lock usually fits. If the device is shared, unattended for longer periods, or expected to leave a controlled environment, logout is the safer boundary.

How device class and local persistence should drive the rule

Different device classes create different exposure. On a managed workstation with strong local protections, locking may be enough because the device and its storage remain under policy control. On mobile devices, shared kiosks, contractor laptops, or any endpoint with weaker assurance, logout should be favored because local persistence can outlive the current user’s intent.

CIS Controls v8 supports this kind of decision by linking endpoint protection to account management, access control, and data protection. The practical implication is to define which device classes may retain active local state after use, then make logout the default wherever that local state would widen exposure.

NIST SP 800-53 Rev 5 Security and Privacy Controls also maps cleanly to the choice, especially where session handling, access control, and auditability matter. Use it to justify a stricter logout rule for endpoints that handle sensitive data or that cannot be reliably assumed to stay under trusted control.

Risk and Threat Considerations

The main risk is mistaking temporary convenience for safe continuity. If a device is merely locked, locally cached data, active application state, or a still-valid authenticated context may remain available to the next person who can unlock or reuse the endpoint. That creates a theft, shoulder-surfing, or post-session access problem even when no password has been exposed.

Failure mechanism: A lock preserves the local session state, so any residual access, cached data, or unlocked-by-proxy condition remains available if the endpoint is later reached by an unintended user or process.

Impact: Sensitive data can remain retrievable on the device, shared endpoints can expose another user’s context, and the organisation may lose control over how long access truly persists after the original user steps away.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-5 — Account Management	Device session choice affects account access persistence and local exposure.
Recommendation — Set clear lock and logout rules by device class and access sensitivity.
NIST SP 800-53 Rev 5	AC-2 — Account Management	Logout policy determines when account access should end on an endpoint.
	AC-11 — Device Lock	Locking is the explicit control for short-term unattended device protection.
	AC-12 — Session Termination	Logout is session termination and removes retrievable local context.
Recommendation — Require logout when local session persistence should end. Use device lock for brief absences on trusted endpoints. Terminate sessions when the device should not retain recoverable access.
ISO/IEC 27001:2022	A.5.15 — Access control	The decision governs whether local access remains acceptable after use.
	A.8.5 — Secure authentication	Ending or preserving authenticated state directly changes exposure on the endpoint.
Recommendation — Define access rules that distinguish temporary lock from full logout. Require logout whenever authenticated state should not persist locally.

Practitioner Guidance

What to prioritise: Define one clear rule per device class, based on whether local persistence is acceptable. If the endpoint can be trusted to remain under the same user’s control for a short period, lock is a convenience control. If the device may change hands, leave a trusted zone, or keep sensitive local state, logout should be the default.

What to verify: Confirm whether the device actually stores retrievable vault material, tokens, or cached application data after lock. If it does, locking is only acceptable when that residual state is an intentional and documented design choice.

Decision rule: If you would be comfortable with the next legitimate user resuming the same local context, lock is reasonable. If you need the endpoint to forget the context before reuse, logout is the correct action.

Practitioner takeaway: Make lock about short-term convenience and logout about ending local trust. The safest rule is the one that matches how much residual access you are willing to leave behind on that specific device.