Terminate (automatically) a user session after a defined condition
📖 What This Means
This control requires systems to automatically log users out after a period of inactivity or other defined condition (like a security event). Think of it like a bank's website that logs you out if you walk away from your computer—it prevents unauthorized access if you forget to log out. For example, a defense contractor's internal system might terminate sessions after 15 minutes of inactivity, or immediately if a user tries to access restricted data without proper permissions. This is about reducing risk when people forget or fail to manually log out.
🎯 Why It Matters
Unterminated sessions are a major attack vector. In 2022, 35% of breaches involved stolen credentials (Verizon DBIR). Attackers exploit active sessions to move laterally in networks—like the 2020 SolarWinds breach where hackers used lingering admin sessions. For DoD contractors, an open session on a CUI system could lead to data exfiltration, compliance violations ($20K+ fines per incident), or loss of contracts. CMMC mandates this to enforce 'zero trust' principles—never assuming a session is safe without verification.
✅ How to Implement
- AWS: Set session timeouts in IAM policies (e.g., `aws iam update-account-password-policy --max-session-duration 3600`)
- Azure: Configure conditional access policies in Entra ID (Azure AD) under Security > Session controls
- GCP: Use Session Timeout in Identity-Aware Proxy (IAP) settings
- Enable CloudTrail/Azure Monitor to log session termination events
- Enforce timeout rules via Terraform (e.g., `google_iap_web_iam_policy` resource)
📋 Evidence Examples
Session timeout policy
GPO screenshot
Azure session logs
Test results
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For AC.L2-3.1.11 ("Terminate (automatically) a user session after a defined condition"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how access to CUI systems is controlled, including the specific IAM tools, policies, and processes used. Reference your Access Control Policy and identify the systems in scope. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"AC.L2-3.1.11 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to terminate (automatically) a user session after a defined condition. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"AC.L2-3.1.11 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to terminate (automatically) a user session after a defined condition. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"AC.L2-3.1.11 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all access points to CUI systems (VPN, direct network, cloud portals)
- • Document which IAM system manages access (Azure AD, AWS IAM, on-prem AD)
- • Map user roles to system access levels
- • Ensure this control covers all systems within your defined CUI boundary where terminate (automatically) a user session after a defined condition applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Access Control Policy
- 📄 IAM configuration documentation
- 📄 Access request and approval records
- 📄 Evidence artifacts specific to AC.L2-3.1.11
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will verify that access controls are implemented as described, test whether unauthorized users are blocked, and review access logs for evidence of enforcement.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do all systems handling CUI have documented session timeout values?
Question 2: Are timeouts enforced via technical controls (not just policy)?
Question 3: Are termination events logged and retained for 90+ days?
Question 4: Is there quarterly testing to verify timeouts work?
⚠️ Common Mistakes (What Auditors Flag)
1. Only setting timeouts for some systems
2. No logging of termination events
3. Overly long timeouts (e.g., 8 hours)
4. Missing mobile device timeouts
📚 Parent Policy
This practice is governed by the Access Control Policy