AC-2(5): Inactivity Logout

AC-2(5) requires you to force a user logout after a defined period of inactivity (or a defined inactivity condition) so unattended sessions cannot be reused. To operationalize it, pick an inactivity threshold per system risk, configure automatic logout at the application/SSO/OS level, document exceptions, and keep configuration and test evidence that proves the setting works in production. ¹

Key takeaways:

• Define “inactivity” and the logout trigger per system and user context, then enforce it technically (not by policy alone). ²
• Centralize control ownership and evidence: configs, screenshots/exports, test results, and exception approvals. ²
• Audit readiness depends on demonstrating consistent enforcement across endpoints, apps, remote access, and privileged access paths. ³

AC-2(5): Inactivity Logout sits in the Account Management family, but it’s really a session control problem: if a session remains active while the user is away, anyone with physical or logical access can act under that identity. That risk shows up in shared work areas, remote work, jump hosts, admin consoles, call centers, clinical/field environments, and anywhere a browser session stays open.

For a Compliance Officer or GRC lead, the fastest path is to treat AC-2(5) as a “configuration-backed requirement” with three pillars: (1) a defined inactivity threshold or condition, (2) technical enforcement across the major session layers (endpoint, OS lock/logout, SSO, application session timeout, and remote access), and (3) evidence that the control is operating, not just designed.

This page gives you requirement-level implementation guidance you can hand to IAM, endpoint engineering, and application owners. It also calls out where teams commonly fail audits: inconsistent timeouts, “lock screen” mistaken for “logout,” gaps for privileged/admin interfaces, and undocumented exceptions. Primary references are NIST SP 800-53 Rev. 5 materials. ²

Regulatory text

NIST AC-2(5): Inactivity Logout: “Require that users log out when [time period of expected inactivity or description of when to log out].” ¹

What the operator must do

1. Specify the inactivity trigger: define the time period or condition that counts as “expected inactivity” for each in-scope system or system class. ¹
2. Enforce logout: implement technical controls that end the user session after the defined inactivity condition. Policy language alone does not satisfy the requirement. ²
3. Prove it works: retain evidence showing the setting is configured, deployed to production, and effective via testing or monitoring. ³

Plain-English interpretation (what AC-2(5) really means)

You must prevent “walk-up reuse” of unattended sessions by automatically logging users out after inactivity. In practice, this means you choose an inactivity timeout (or comparable rule) appropriate to the system’s risk and workflow, then configure the technology stack so the session terminates and requires re-authentication.

Key nuance: logout is stronger than screen lock. A locked workstation may preserve application sessions; a logout ends the session and typically clears session tokens/cookies for the application context. Your implementation can include multiple layers (screen lock plus app timeout), but AC-2(5) is explicitly about logging out. ³

Who it applies to (entity and operational context)

AC-2(5) commonly applies when you align to NIST SP 800-53 for:

• Federal information systems
• Federal contractors
• Contractor systems handling federal data
• Service organizations supporting customers that require NIST-aligned controls (for example, via contracts, ATO boundaries, or customer security requirements). ²

Operational contexts where auditors probe hardest

• Privileged access paths: admin consoles, cloud control planes, hypervisors, databases, CI/CD, secrets managers, MDM consoles.
• Remote access: VPN, VDI, bastions/jump hosts, RDP gateways.
• Shared or semi-shared devices: kiosks, call center terminals, lab systems.
• Web apps with long-lived cookies: internal portals, ticketing tools, HR/finance tools, customer support tooling.

What you actually need to do (step-by-step)

Step 1: Define scope and the logout standard (policy + control card)

Create a short, enforceable standard that answers:

• Which systems are in scope (production, staging, admin planes, endpoints, VDI, SaaS)?
• What counts as inactivity (no keyboard/mouse, no HTTP requests, no privileged action)?
• What action occurs (application logout, IdP session termination, token revocation, remote session disconnect)?
• Where exceptions are allowed (and who approves them). ²

Operationalize this as a one-page control card:

• Objective: force logout after inactivity to reduce unauthorized use of unattended sessions.
• Owner: IAM for SSO policies; endpoint team for device controls; app owners for app sessions.
• Cadence: configuration continuously enforced; health checks run on a defined cadence.
• Exception rules: documented, risk-accepted, time-bound.

Daydream note: many teams store the control card, owners, and evidence links in Daydream so auditors can trace “requirement → systems → configs → tests → exceptions” without hunting across wikis and tickets. ²

Step 2: Set the inactivity threshold by risk tier (decision matrix)

NIST leaves the time period blank by design; you must fill it in. Use a tiered approach to avoid endless debates.

System / session type	Data & privilege profile	Recommended approach to define timeout (no fixed numbers)
Privileged admin consoles	High privilege, high blast radius	Shorter inactivity threshold; no “remember me”; re-auth for sensitive actions
General workforce apps	Standard access	Moderate threshold consistent across major apps via IdP/session policy
Shared terminals/kiosks	High physical exposure	Aggressive logout with minimal exception allowance
Remote access (VPN/VDI)	External access path	Enforce idle disconnect + re-auth on reconnect

Document the rationale per tier in your standard and map each in-scope system to a tier.

Step 3: Implement logout controls at the right layers

You usually need more than one control point.

A. Identity provider (SSO) session policies

• Configure IdP session idle timeout and maximum session lifetime.
• Disable persistent sessions where risk demands it.
• Confirm downstream apps respect IdP session expiry, or add app-level timeouts. ²

B. Application session management

• Configure application idle timeout to terminate sessions.
• Ensure logout invalidates server-side sessions (not only client-side UI state).
• For modern auth (OIDC/SAML), confirm refresh tokens and session cookies expire appropriately. ³

C. Endpoint and OS controls

• Configure workstation policies that log out users after inactivity where feasible, or pair screen lock with enforced application timeouts if full OS logout is operationally disruptive.
• For shared devices, prefer kiosk modes with session reset on inactivity. ³

D. Remote access / bastion controls

• Enforce idle disconnect on VPN/VDI and privileged jump hosts.
• Ensure reconnect requires re-authentication, especially for admin groups. ²

Step 4: Test and validate (make it audit-proof)

Create a repeatable test script per platform:

• Confirm timeout value matches the standard for that tier.
• Start a session, go idle past the threshold/condition, verify logout occurs.
• Attempt to reuse the session (back button, cached tab, token reuse) and confirm re-auth is required.
• Capture evidence (screenshots, logs, exports) and store centrally. ³

Step 5: Exceptions and compensating controls

You will face real operational exceptions (batch operations, monitoring dashboards, trading floors, manufacturing). Handle them explicitly:

• Require a written exception request with system, role group, justification, and duration.
• Implement compensating controls (for example, privileged re-auth for sensitive actions, step-up MFA, restricted network segments, or dedicated accounts with monitoring).
• Time-box the exception and require re-approval. ²

Required evidence and artifacts to retain

Keep evidence that answers “what is the requirement, where is it enforced, and how do you know it works?”

Minimum evidence bundle (practical)

• Control card / control narrative for AC-2(5): scope, owner, enforcement points, exception workflow.
• Standard or configuration baseline stating inactivity logout rules per tier/system class.
• System inventory mapping: list of in-scope systems with their tier and enforcement method.
• Configuration evidence ³:
  • IdP policy export or screenshots of session timeout settings
  • MDM/GPO/endpoint policy exports
  • App configuration screenshots or config-as-code snippets
  • Remote access policy configuration (VPN/VDI/bastion)
• Test evidence: dated test results, scripts, and outcomes for representative systems in each tier.
• Exception register: approvals, risk acceptance, compensating controls, and expiry dates.
• Control health check records: periodic checks and remediation tickets to closure. ²

Daydream note: a common pattern is to attach the policy exports, test runs, and exception register as a “minimum evidence bundle” to the requirement in Daydream so audits become a packaging exercise, not a scavenger hunt. ²

Common exam/audit questions and hangups

Expect these questions from assessors, customers, and internal audit:

1. “What is your inactivity period, and where is it defined?” They want a standard, not tribal knowledge. ¹
2. “Show me it’s enforced in production.” Screenshots from a test tenant are weak; provide production policy exports or change records. ³
3. “Is this logout or just screen lock?” Be ready to demonstrate session termination for critical apps. ³
4. “How do you cover privileged access?” Auditors focus on admin planes and shared admin accounts. ²
5. “How do exceptions work?” They will ask for the exception list, approvals, and compensating controls. ³

Frequent implementation mistakes (and how to avoid them)

1. Relying on workstation lock only

   • Fix: require app/SSO logout behavior for high-risk systems; validate tokens expire and sessions cannot be resumed. ³

2. Inconsistent settings across layers

   • Fix: set a clear hierarchy (IdP baseline + app overrides) and document which layer is authoritative for each system. ²

3. Forgetting non-browser sessions

   • Fix: include VPN/VDI, SSH bastions, and thick clients in scope and evidence. ³

4. No proof of operation

   • Fix: schedule control health checks and retain exports/logs that demonstrate settings stayed in place after changes. ²

5. Exceptions without expiry

   • Fix: time-box exceptions with a defined re-approval trigger and track them in an exception register. ³

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this guidance focuses on audit and assessment expectations rather than specific enforcement outcomes. ²

Risk-wise, inactivity logout failures tend to surface during incident reviews as “session left open,” “shared device used by another person,” or “admin console left unattended.” From an assessment standpoint, weak or inconsistent session termination is easy to demonstrate and hard to explain away if you lack standardization and evidence. ³

A practical 30/60/90-day execution plan

First 30 days (stabilize the requirement)

• Assign a single control owner and name technical owners for IdP, endpoints, remote access, and top applications.
• Write the inactivity logout standard with tiers and an exception workflow.
• Build an inventory slice: list the highest-risk systems (admin consoles, VPN/VDI, bastions) and document current timeout behavior.
• Start capturing “as-is” configuration exports and gaps in a remediation tracker. ²

Days 31–60 (implement and prove)

• Implement IdP session idle timeout and maximum session lifetime aligned to your tiers.
• Implement app-level timeouts for apps that do not inherit IdP behavior cleanly.
• Implement idle disconnect for remote access and bastion tooling.
• Run test scripts for at least one representative system per tier and store evidence centrally.
• Stand up an exception register and route the first exception requests through it. ³

Days 61–90 (operate and harden)

• Expand coverage across the full in-scope inventory; prioritize systems with privileged roles and shared devices.
• Add continuous configuration checks where possible (config-as-code checks, MDM compliance reporting, IdP policy monitoring).
• Run the first formal control health check, document results, and close remediation items with validation evidence.
• Package the “audit-ready bundle” (control card, standard, inventory mapping, configs, tests, exceptions) in a single location (Daydream or your GRC repository). ²

Frequently Asked Questions

Does AC-2(5) require a specific inactivity timeout value?

No. NIST leaves the time period or condition to you to define based on expected inactivity and risk. You must document the value/condition and enforce it technically. ¹

Is a locked screen sufficient to meet “inactivity logout”?

A lock screen reduces physical access risk, but it may not terminate application sessions. For AC-2(5), you should be able to show that sessions end and require re-authentication after inactivity for in-scope systems, especially privileged ones. ³

How do we handle SaaS applications where we can’t set an app-level timeout?

Start with IdP session policies and confirm the SaaS honors IdP session expiration. If the SaaS cannot meet your standard, document the limitation, add compensating controls, and track it as a risk/exception with an owner. ²

What’s the best evidence for auditors?

Provide production configuration exports (IdP, MDM/GPO, VPN/VDI, app settings), a small set of test results that demonstrate actual logout behavior, and an exception register with approvals. Keep it mapped to the system inventory. ³

Do service accounts and API tokens fall under inactivity logout?

AC-2(5) is written for user logout after inactivity, so it maps most directly to interactive sessions. For non-interactive tokens, address session/token lifetime and revocation in your broader access control and authentication controls, and document the boundary. ²

How do we keep this from regressing after IT changes?

Put the setting into your baseline configuration (IdP policies, MDM profiles, infrastructure/app config) and run recurring health checks with tracked remediation to closure. Store evidence per cycle so you can show ongoing operation. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5 PDF

3. NIST SP 800-53 Rev. 5