Device Lock

Device lock requirements form a fundamental access control in the FedRAMP Moderate baseline, mandating automatic session termination after periods of inactivity. Under NIST SP 800-53 Rev 5 AC-11, organizations must implement technical controls that prevent unauthorized access to unattended systems by enforcing automatic locks and requiring proper authentication to regain access.

The control addresses a straightforward security gap: users who walk away from active sessions create opportunities for unauthorized access. While conceptually simple, proper implementation requires careful consideration of organizational needs, technical capabilities across diverse system types, and the balance between security and operational efficiency. Federal systems and cloud service providers pursuing FedRAMP authorization must demonstrate consistent device lock implementation across all information system components, from traditional workstations to containerized applications.

Regulatory text

The NIST SP 800-53 Rev 5 AC-11 control states: "Prevent further access to the system by initiating a device lock after an organization-defined time period of inactivity; and retain the device lock until the user reestablishes access using established identification and authentication procedures."

This requirement mandates two distinct technical capabilities:

1. Automatic session locking triggered by inactivity timers
2. Authentication-based unlocking that requires users to prove their identity before resuming work

The phrase "organization-defined time period" grants flexibility but also creates an obligation to document and justify your chosen timeout values. During FedRAMP assessments, auditors expect to see rational timeout periods based on system criticality and operational context.

Who This Applies To

Device lock requirements apply to:

• Cloud Service Providers (CSPs) seeking FedRAMP authorization at Moderate or High baselines
• Federal agencies implementing NIST controls for internal systems
• Contractors and third parties accessing federal information systems
• Any organization adopting NIST SP 800-53 as their security framework

The control covers all information system types:

• End-user workstations and laptops
• Administrative jump boxes and privileged access workstations
• Server console sessions (physical and virtual)
• Mobile devices processing federal data
• Web applications and SaaS platforms
• Remote access sessions (RDP, SSH, VPN clients)

Step-by-Step Implementation Guide

Phase 1: Define Timeout Values

Start by establishing timeout periods for each system category. Document these values in your System Security Plan (SSP) with justification for each choice.

Typical timeout values by system type:

• Standard workstations: 15 minutes
• Privileged administrative sessions: 5-10 minutes
• Public kiosks or shared terminals: 2-5 minutes
• Mobile devices: 5 minutes
• Server console sessions: 15-30 minutes

Phase 2: Configure Technical Controls

Windows Systems:

1. Deploy Group Policy settings for screen saver timeouts
2. Enable "On resume, display logon screen" option
3. Set machine inactivity limits via Local Security Policy
4. Configure PowerShell execution policies to prevent timeout bypasses

Linux/Unix Systems:

1. Configure TMOUT variable in /etc/profile
2. Set SSH ClientAliveInterval and ClientAliveCountMax
3. Implement screen or tmux session timeouts
4. Deploy PAM modules for session management

Web Applications:

1. Implement session timeout in application code
2. Configure load balancer idle timeouts
3. Set cookie expiration aligned with timeout values
4. Implement client-side warning messages before timeout

Mobile Devices:

1. Deploy MDM policies for screen lock timeouts
2. Require PIN/biometric for unlock
3. Configure app-specific timeouts for federal data access
4. Enable remote wipe capabilities

Phase 3: Handle Special Cases

Several scenarios require additional consideration:

Long-Running Processes: Systems executing batch jobs or lengthy computations need exemption procedures. Document these exceptions with:

• Business justification for extended sessions
• Compensating controls (isolated networks, enhanced monitoring)
• Approval workflow for timeout extensions
• Regular review of exempted systems

Shared Workstations: Devices used by multiple operators need aggressive timeout values and clear session handoff procedures. Implement:

• Shortened timeouts (2-5 minutes)
• Forced logoff between users
• Session activity logging
• User training on proper logout procedures

Remote Access: VPN and remote desktop sessions require aligned timeout values across multiple control points:

• VPN client idle timeout
• Remote desktop session timeout
• Application-layer timeout
• Token/certificate validity periods

Required Evidence and Artifacts

Maintain these artifacts for audit readiness:

1. Configuration Standards: Document showing timeout values for each system type with business justification

2. Technical Implementation Evidence:

   • Group Policy reports showing enforced settings
   • Configuration files from Linux/Unix systems
   • Application code snippets implementing session timeout
   • MDM policy screenshots for mobile devices

3. Testing Results: Reports demonstrating timeout enforcement:

   • Screen captures showing lock screens after inactivity
   • Log entries showing session termination events
   • Penetration test results validating re-authentication requirements

4. Exception Documentation:

   • List of systems with extended/disabled timeouts
   • Business justification for each exception
   • Compensating control descriptions
   • Management approval records

5. User Awareness Materials: Training content explaining device lock requirements and procedures

Common Audit Questions and Responses

Auditors consistently focus on these areas:

"How did you determine your timeout values?" Provide your documented risk assessment showing how timeout values balance security requirements with operational needs. Reference specific mission functions that informed your decisions.

"Show me timeout enforcement on [random system]" Demonstrate the control live or provide recent screenshots. Have remote access ready to multiple system types. Know how to quickly display Group Policy results or check Linux environment variables.

"What happens if someone bypasses the screensaver?" Show your controls preventing timeout bypass: disabled registry editing, blocked screensaver configuration changes, application whitelisting preventing unauthorized tools.

"How do you handle service accounts?" Document your approach to non-interactive accounts. Show how service accounts either cannot establish interactive sessions or operate under compensating controls.

Implementation Mistakes to Avoid

Inconsistent Timeout Values: The most common failure involves different timeout settings across similar systems. A Windows workstation with 15-minute timeout while another uses 30 minutes raises immediate red flags. Maintain standardization within system categories.

Weak Re-authentication: Some organizations implement "unlock" features that don't require full authentication. Smart card removal should lock the system, but unlocking must require both the card AND PIN. Password-protected screensavers must enforce the same complexity rules as initial login.

Missing System Types: Organizations often overlook:

• Administrator jump boxes
• Database client sessions
• Development environments
• Virtual desktop infrastructure (VDI) sessions
• Containerized application consoles

Inadequate Exception Handling: Undocumented exceptions sink otherwise solid implementations. Every system requiring extended timeouts needs formal documentation, not just technical configuration.

30/60/90-Day Execution Plan

Immediate Actions (Days 1-30):

• Inventory all information system types requiring device lock controls
• Document current timeout configurations across the environment
• Identify systems lacking timeout enforcement
• Draft organization-defined timeout values for SSP inclusion

Near-term Implementation (Days 31-60):

• Deploy Group Policy changes for Windows environments
• Configure Linux/Unix system timeouts via configuration management
• Update application session timeout values
• Begin user communication about upcoming timeout changes

Ongoing Maturation (Days 61-90):

• Conduct timeout testing across all system types
• Document exceptions with proper approvals
• Generate compliance reports from technical controls
• Schedule quarterly reviews of timeout values and exceptions

Frequently Asked Questions

Do virtual machines require separate device lock controls if the host system locks?

Yes, each virtual machine requires independent timeout configuration. Host system locks don't propagate to guest VMs, and users might access VMs through other methods bypassing host controls.

How should we handle kiosk systems that need to stay active for public use?

Kiosk systems require session termination between users rather than traditional screen locks. Implement application-level timeouts that return to a "home" state and clear any user data after inactivity.

Can we use different timeout values for different user roles?

Yes, role-based timeout values are acceptable if documented and technically enforced. Privileged users often require shorter timeouts than standard users. Document the risk-based rationale in your SSP.

What if our legacy application doesn't support session timeouts?

Document the limitation as a risk in your POA&M. Implement compensating controls such as network isolation, enhanced logging, and regular session audits. Plan for application updates or replacement.

Do mobile devices require lock screens if they use app-specific authentication?

Yes, device-level locks are required regardless of app-level controls. FedRAMP expects defense-in-depth with both device locks (PIN/biometric) and app-specific authentication for federal data access.

How do we prove timeout enforcement during remote audits?

Prepare video demonstrations showing timeout behavior, collect timestamped screenshots of lock screens, and gather system logs showing session termination events. Have remote access ready for live demonstrations.