AC-2(5): Inactivity Logout

AC-2(5) requires you to force a user logout after a defined period of inactivity (your organization-defined parameter) across in-scope systems, then prove it works. Operationalize it by setting an inactivity threshold per system class, implementing technical session termination controls, handling exceptions explicitly, and collecting configuration and test evidence on a recurring cadence. ¹

Key takeaways:

• Define and approve the inactivity threshold (the “ODP”) per environment and risk tier, then standardize it.
• Implement enforced logout at the session layer (not just a screen lock) for each in-scope application and access path.
• Retain evidence that is audit-ready: config snapshots, exception register, and periodic test results tied to system inventory.

The ac-2(5): inactivity logout requirement is deceptively simple: users must be logged out when inactivity hits a defined threshold. In audits, this control fails less from missing intent and more from inconsistent implementation across systems, weak definitions (no agreed threshold), and thin evidence (a policy statement without proof the setting exists and is enforced).

For a CCO or GRC lead, the fastest path is to treat AC-2(5) as a requirement you can run like a control: name an owner, define the “organization-defined parameter” (ODP) for inactivity, apply it to a scoped system population, and validate it keeps working after releases and configuration changes. You also need to anticipate operational exceptions (kiosks, call centers, OT/ICS consoles, shared service accounts, batch jobs) and document compensating safeguards where forced logout is not feasible.

This page gives you requirement-level implementation guidance: who it applies to, what to configure, how to test, what evidence to keep, and the exam questions you should expect.

Regulatory text

Requirement (excerpt): “Require that users log out when {{ insert: param, ac-02.05_odp }}.” ¹

What the operator must do:

1. Define the inactivity condition (the ODP) that triggers logout, 2) implement technical enforcement so sessions terminate (logout) after that inactivity period, and 3) operate it continuously across in-scope systems with evidence. The key word is log out: this is stronger than a screen lock or screensaver, because it ends the authenticated session and reduces session hijack and shoulder-surf continuation risks. ²

Plain-English interpretation

AC-2(5) expects that if a user walks away (or leaves a browser tab open) and does nothing for your defined time, the system ends their session and requires re-authentication. You pick the inactivity threshold, but you must be able to explain why it fits the system’s risk and show it is consistently enforced.

The practical compliance bar is:

• Defined: inactivity is clearly defined (interactive session inactivity, not total time logged in).
• Enforced: technical controls actually terminate sessions.
• Consistent: applied across the scoped population, not just a few “key” apps.
• Provable: evidence exists for configs, exceptions, and periodic validation. ²

Who it applies to (entity and operational context)

AC-2(5) commonly applies where you adopt NIST SP 800-53 controls, including:

• Federal information systems and programs aligned to NIST control baselines. ²
• Federal contractors and contractor systems handling federal data, including service organizations operating systems for federal customers. ²

Operationally, scope it to:

• Interactive user sessions to business applications (web, desktop, mobile).
• Privileged access paths (admin consoles, bastions/jump hosts).
• Remote access/VPN portals and VDI.
• Shared workstations, kiosks, and call-center endpoints (often via exception with compensating controls, if needed).

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

1) Create a “control card” so this can run repeatedly

Write a one-page runbook for AC-2(5) that includes: objective, scope, owner, systems in scope, the inactivity ODP, how enforcement is implemented per platform, test method, exceptions, and evidence location. This becomes the reference for audits and internal handoffs. ²

Minimum fields to include:

• Control owner (typically IAM lead or platform security).
• Systems of record: CMDB/app inventory list used for scope.
• ODP definition: what counts as inactivity; what action equals “logout.”
• Enforcement mechanisms by system type (IdP, web app, OS/MDM, VPN).
• Exception criteria and approval authority.

2) Define the inactivity ODP (and don’t leave it vague)

Your ODP must answer:

• What sessions are covered (interactive human sessions, privileged sessions, support tools)?
• What “inactivity” means (no keyboard/mouse input, no HTTP requests, no token refresh)?
• What “logout” means (server-side session invalidation, token revocation, forced re-authentication).

Set the ODP per risk tier (for example: standard apps vs. privileged admin). Keep it simple enough that engineering teams can implement it consistently.

Deliverable: an approved configuration standard (or security baseline) that states the inactivity thresholds and where they must be enforced.

3) Map enforcement points by architecture (where to implement)

Decide where logout is technically enforced for each system:

Common enforcement layers

• Identity provider / SSO: session lifetime and idle timeout settings for federated sessions.
• Application layer: server-side session timeout and invalidation; front-end timeouts alone are not sufficient.
• Device management: workstation policies that terminate sessions or require sign-in again (note: screen lock alone may not satisfy “logout” for application sessions).
• Remote access / VPN / VDI: idle disconnect plus session termination for the gateway.

Create a simple matrix (system → enforcement layer → setting name → owner). This prevents “everyone thought someone else did it.”

4) Implement settings and make them resilient to drift

For each platform, implement the timeout as code or centrally managed configuration where possible:

• Configuration management (policy-as-code, device profiles, IdP tenant settings under change control).
• Standard app libraries/middleware for session management.
• Release gates: add a security check that session timeouts are present and match the standard.

Also define what happens after timeout:

• Re-auth required (and MFA re-challenge for higher-risk contexts where your policy requires it).
• Tokens/sessions invalidated server-side, not just hidden UI.

5) Handle exceptions with explicit compensating controls

You will encounter legitimate edge cases:

• Shared kiosks that must remain available.
• OT/ICS consoles with stability constraints.
• Long-running clinical or support workflows where logout disrupts operations.

Treat each as a documented exception:

• Business justification and system owner.
• Duration (temporary vs. standing).
• Compensating controls (restricted network segment, physical controls, monitoring, dedicated accounts, shorter re-auth boundaries elsewhere).
• Approval and periodic review.

Auditors usually accept exceptions when they are specific, approved, and reviewed. They reject “we can’t do that” with no artifact trail.

6) Test it like an auditor would

A lightweight test plan beats a policy statement. For each major platform:

• Start a session as a normal user.
• Go inactive past the configured threshold.
• Confirm the system forces logout and requires re-authentication.
• Repeat for a privileged session path.

Record evidence (screenshots, logs, exported settings) and tie it to the system name and date.

7) Establish a control health check cadence

Set a recurring review that checks:

• Config still matches the standard.
• New systems are onboarded with the correct setting.
• Exceptions are still justified.

Track issues to closure with dates, owners, and proof of remediation. This is how you show “operating effectiveness,” not just design. ²

Required evidence and artifacts to retain

Keep evidence in an audit-ready folder mapped to your system inventory. Minimum bundle:

• Control card / runbook with owner, scope, ODP, and procedures. ²
• Approved standard that defines inactivity threshold(s) and logout requirements.
• System-to-setting matrix (inventory mapping).
• Configuration exports/snapshots from IdP/VPN/MDM/app config showing idle timeout and session termination settings.
• Test results (screenshots, logs, or scripted validation output) showing forced logout after inactivity.
• Exception register with approvals and compensating controls.
• Change records for updates to timeout settings (tickets/PRs) tied to the systems changed.
• Control health check logs and remediation tracker. ²

If you use Daydream, store the control card, evidence checklist, and recurring test attestations in one place so you can answer customer and auditor requests without rebuilding the story each time.

Common exam/audit questions and hangups

Expect these:

• “What is your organization-defined inactivity threshold, and who approved it?”
• “Show me where this is enforced for SSO sessions versus application sessions.”
• “Demonstrate it working for a real application and a privileged access path.”
• “How do you ensure new applications inherit the standard?”
• “List all exceptions and show compensating controls and review history.”

Hangups that trigger findings:

• “Logout” implemented as screen lock only, while the app session persists.
• Timeouts configured in one place (IdP) but overridden or bypassed in the app.
• No proof of ongoing operation after initial setup.

Frequent implementation mistakes and how to avoid them

1. Confusing idle timeout with absolute session lifetime
   Avoidance: define both concepts internally, but document AC-2(5) as idle inactivity logout; implement both where appropriate.

2. Client-side timers only
   Avoidance: require server-side session invalidation. Front-end timers can be bypassed or fail silently.

3. One-size-fits-all without scoping
   Avoidance: tier systems. Privileged consoles and sensitive apps should not inherit relaxed settings from low-risk tools.

4. Exceptions hidden in tribal knowledge
   Avoidance: keep a formal exception register with approvals and periodic review.

5. No linkage to inventory
   Avoidance: map every in-scope system to an enforcement point and an accountable owner.

Enforcement context and risk implications

No public enforcement cases were provided in the source materials for this requirement, so you should treat enforcement expectations as coming from audits, customer diligence, and contractual security requirements rather than citing specific case law.

Risk-wise, inactivity logout reduces:

• Unauthorized access when a device is unattended.
• Session reuse by someone with physical access.
• Persisting authenticated browser sessions in shared environments.

The compliance risk usually shows up as “control not consistently implemented” or “control not operating effectively,” especially when you cannot demonstrate enforcement across a representative sample of systems. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and decisions)

• Assign an owner and publish the AC-2(5) control card (objective, scope, ODP placeholder, evidence list). ²
• Build the in-scope inventory list (apps, VPN/VDI, admin paths).
• Decide and approve the inactivity ODP per tier (standard vs. privileged).
• Identify systems that cannot comply and open exception requests.

By 60 days (implement and prove)

• Configure enforcement in your IdP/SSO, VPN/VDI, and device management baselines.
• Update top business-critical applications to enforce server-side session invalidation.
• Run and record tests for representative systems in each tier.
• Finalize exception register with compensating controls and approvals.

By 90 days (operate and prevent drift)

• Add onboarding checks so new apps must declare their timeout settings before go-live.
• Schedule recurring health checks (config verification + exception review) and track remediation through closure. ²
• Consolidate evidence in a single repository (Daydream or your GRC system) with clear naming tied to inventory.

Frequently Asked Questions

What counts as “logout” for AC-2(5) in a web application?

Treat logout as server-side session termination that forces re-authentication after inactivity. A front-end pop-up or client-side redirect alone is weak evidence because the server session may still be valid.

Can we satisfy AC-2(5) with an endpoint screen lock policy?

Screen locks help, but AC-2(5) language is about users logging out after inactivity. If the application session remains authenticated after unlock, an auditor may treat it as not meeting the requirement.

How should we set the inactivity threshold if the control lets us define it?

Choose a threshold per risk tier and document the rationale and approval. Auditors focus less on the specific number and more on consistency, enforcement, and evidence that it works.

What systems should we prioritize first?

Start with privileged access paths (admin consoles, bastions, cloud consoles) and remote access (VPN/VDI), then cover high-risk business apps. Those are the places where unattended sessions create the most immediate exposure.

How do we manage exceptions without failing audits?

Use a written exception workflow with an approver, compensating controls, and periodic review. Keep exceptions specific to a system and documented in an exception register that you can produce on request.

What’s the minimum evidence an auditor will accept?

A defined ODP, configuration proof from enforcement points (IdP/app/VPN/MDM), and a test record that shows inactivity leads to logout for sampled systems. Add an exception register if any systems cannot comply.

Footnotes

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

2. NIST SP 800-53 Rev. 5