Skip to main content
Comply Defense
Category: Identity & Access Management

Session Lock

Also known as: Device Lock, AC-11
Simply put

A session lock is a security measure that blocks access to a computer or system after a set period of inactivity, requiring the user to re-authenticate (for example, by re-entering a password) before they can continue working. It is meant to prevent someone from using an unattended device or account without the authorized user present. It temporarily hides the screen or interface rather than logging the user out entirely.

Formal definition

In the NIST access control context, a session lock is a control that initiates a lock over an information system or device session after an organization-defined period of user inactivity (or upon user request), retaining the session but concealing information previously visible on the display and preventing further access until the user re-establishes access through identification and authentication procedures. This concept is addressed in NIST SP 800-53 as control AC-11; note that the control was titled 'Session Lock' in Revision 4 and was renamed 'Device Lock' in Revision 5, so practitioners should confirm the terminology against the applicable revision. A conceptually related requirement appears in NIST SP 800-171 addressing protection of Controlled Unclassified Information (CUI) in nonfederal systems. A session lock is generally distinct from a full session termination or logout, and specific inactivity periods, applicability, and any concealment or pattern-hiding requirements are typically defined through organizational tailoring and the selected baseline; readers should verify exact control text, numbering, and parameter values against the current authoritative NIST publication.

Why it matters

Session lock is a foundational access control that addresses one of the most common and preventable exposures in any environment: the unattended, unlocked workstation. When a user steps away from an authenticated session without logging off, anyone with physical access to that device can view sensitive information or act under the authorized user's identity. In defense and public sector contexts where systems process Controlled Unclassified Information (CUI) or support DoD operations, this risk is not merely theoretical, since shared workspaces, common-access facilities, and multi-user environments increase the likelihood of opportunistic access to an idle session.

Because a session lock conceals previously displayed information and requires re-authentication before work can resume, it enforces the principle that access should be continuously tied to the presence of the authorized user rather than to a single point-in-time login. Practitioners should note that a session lock is generally distinct from a full logout or session termination; it retains the session while blocking access, which supports usability without sacrificing the protection against unauthorized use of an unattended device.

Who it's relevant to

Information System Security Managers (ISSMs) and ISSOs
Those responsible for implementing and documenting security controls generally need to configure and validate session lock behavior to align with the organization-defined inactivity period and the applicable baseline. They should confirm whether their system is governed by NIST SP 800-53 (AC-11, titled 'Session Lock' in Rev. 4 and 'Device Lock' in Rev. 5) or the related NIST SP 800-171 requirement, and verify the exact parameter values against the current authoritative text.
Government Contractors Handling CUI
Contractors operating nonfederal systems that store or process Controlled Unclassified Information should be aware that a conceptually related session lock requirement appears in NIST SP 800-171. They should confirm the exact control language and inactivity parameters against the current authoritative NIST publication rather than assuming a specific value, and distinguish session lock from full session termination.
Assessors and Auditors
Personnel evaluating control implementation need to verify that a session lock initiates after the organization-defined period of inactivity (or on user request), conceals previously displayed information, and requires re-authentication before further access. Because the control name changed between revisions, assessors should reference the correct control number and title for the applicable NIST SP 800-53 revision when documenting findings.
Authorizing Officials
Officials accountable for authorization decisions should understand session lock as one access control among those supporting the protection of an unattended session, and should recognize that its specific parameters are set through organizational tailoring and the selected baseline. They should ensure the implemented parameters are consistent with the current authoritative NIST guidance for the applicable revision.

Inside Session Lock

AC-11 (Session Lock control)
The control in NIST SP 800-53 that addresses session lock. It was titled 'Session Lock' in Revision 4 and was renamed 'Device Lock' in Revision 5. Practitioners should verify the current control name and text against the applicable revision, since terminology and organization of the control catalog changed between revisions.
Corresponding NIST SP 800-171 requirement
NIST SP 800-171 addresses the session lock concept as a security requirement for protecting Controlled Unclassified Information (CUI) on nonfederal systems (identified as 3.1.10 in the referenced revision). The exact requirement number and wording should be confirmed against the specific revision of SP 800-171 in effect for a given contract or agreement.
Inactivity-triggered activation
Session lock generally activates after an organization-defined period of inactivity, or upon a user-initiated request. The specific inactivity period is a tailoring parameter set by the implementing organization, not a fixed value defined by the control itself.
Concealment of information on the display
When a session lock engages, it typically hides previously visible information from the display, often by presenting a publicly viewable image such as a blank or pattern screen, so that sensitive data is not exposed to onlookers.
Re-authentication to resume access
A session lock prevents further access to the system until the user re-establishes identity using established authentication and identification procedures. It suspends the session rather than terminating it; session termination is addressed by a distinct control.
Organization-defined parameters
Key elements such as the inactivity time threshold and the concealment method are assignment/selection parameters defined by the organization and may be further tailored through baselines or overlays. Confirm applicable values against your system's security plan and the governing baseline.

Common questions

Answers to the questions practitioners most commonly ask about Session Lock.

Does a session lock end a user's session and log them out?
No. A session lock is distinct from a session termination or logout. Under NIST SP 800-53 AC-11 (titled 'Session Lock' in Revision 4 and 'Device Lock' in Revision 5), a session lock temporarily prevents further access to the system by concealing information on the display after an organization-defined period of inactivity, while retaining the session in place. The user regains access by re-authenticating; the underlying session and its state are not terminated. Session termination is addressed separately (for example, under AC-12 in Revision 5). Treating the two as interchangeable is a common error, a lock pauses access, whereas termination closes the session entirely.
Is session lock the same thing as a simple screen saver?
Not necessarily. While a session lock may be implemented using screen-saver-style functionality that conceals on-screen information, the control's intent under AC-11 is that access is genuinely prevented until the user re-establishes their identity through re-authentication. A screen saver that can be dismissed without re-authentication does not satisfy the control. The distinguishing requirement is that the lock hides previously visible information and blocks further access until the authorized user re-authenticates. Verify the specific implementation details and any organizational tailoring against the applicable revision of the source publication.
Where is the session lock requirement found in NIST guidance?
The requirement is generally expressed in NIST SP 800-53 as control AC-11, maintained by NIST. Note that the control name changed across revisions: it was titled 'Session Lock' in Revision 4 and renamed 'Device Lock' in Revision 5. For systems protecting Controlled Unclassified Information (CUI) in nonfederal systems, the corresponding requirement appears in NIST SP 800-171 (in Revision 3, addressed under the Access Control family). Because control identifiers, titles, and language can shift across revisions and agency tailoring, confirm the applicable revision and the exact control text against the current official NIST publication before relying on it.
What generally triggers a session lock, and how is the inactivity period set?
AC-11 generally triggers a session lock after an organization-defined period of inactivity, and it may also be initiated on demand by the user. The specific inactivity duration is not fixed by the base control; it is an organization-defined parameter that agencies establish through tailoring, and it may vary by system impact level, agency policy, or contractual requirements. Because the value is left to the implementing organization, confirm the required period against your system security plan, applicable baseline, and any agency-specific guidance rather than assuming a single standard value.
How does session lock relate to session termination controls when planning a control implementation?
Session lock (AC-11 / Device Lock in Revision 5) and session termination (addressed separately, for example under AC-12 in Revision 5) are complementary but distinct controls. A session lock conceals information and blocks access after inactivity while preserving the session pending re-authentication, whereas session termination closes the session. In most implementations, organizations apply both to address different risk windows. When documenting your control set, treat them as separate requirements with separate parameters and verify which are included in your applicable baseline, since inclusion can depend on impact level and agency tailoring.
What should be documented to demonstrate compliance with the session lock control during an assessment?
Assessors generally look for evidence that the system conceals previously displayed information upon lock and prevents further access until the user re-authenticates, consistent with AC-11. Practitioners typically document the organization-defined inactivity period, the technical mechanism used, and how re-authentication is enforced, and align these with the system security plan. Keep in mind that demonstrating the control is satisfied is an assessment activity and is distinct from authorization; passing an assessment of this control does not by itself confer an Authority to Operate. Confirm the exact assessment expectations against the current applicable assessment guidance (such as NIST SP 800-53A or the relevant NIST SP 800-171 assessment procedures) and any agency-specific interpretation.

Common misconceptions

Session lock and session termination are the same requirement.
They are distinct concepts addressed by separate controls. A session lock suspends a session and conceals the display until the same user re-authenticates, whereas session termination ends the session after defined conditions. Confirm the exact control designations against the applicable revision of NIST SP 800-53.
The requirement is still universally called 'Session Lock' across all NIST guidance.
The NIST SP 800-53 control was titled 'Session Lock' in Revision 4 but renamed 'Device Lock' in Revision 5. Readers searching for the requirement should account for both names and verify which revision applies to their system.
The control specifies a fixed inactivity timeout that all organizations must use.
The inactivity period is an organization-defined parameter set through tailoring, agency policy, or the applicable baseline, not a single value dictated by the base control. Verify the required value against your security plan and governing authority.

Best practices

Identify the correct control by revision: reference AC-11 as 'Session Lock' when applying NIST SP 800-53 Rev. 4 and as 'Device Lock' when applying Rev. 5, and cross-reference the corresponding SP 800-171 requirement (3.1.10 in the referenced revision) for CUI on nonfederal systems.
Set the inactivity threshold as an explicit organization-defined value documented in the system security plan, and confirm it aligns with your governing baseline, overlay, or agency policy.
Configure the lock to conceal previously displayed information (for example, with a publicly viewable image) so sensitive data is not exposed while the session is suspended.
Require re-authentication using established identification and authentication procedures before access resumes, and verify this behavior during assessment rather than assuming configuration equals compliance.
Distinguish session lock from session termination in your documentation and testing, and address each with its respective control to avoid gaps.
Verify current control names, requirement numbers, and any tailored parameters against the applicable authoritative NIST publications (SP 800-53 and SP 800-171) in effect for your system, since terminology and structure change across revisions.