IAM-012 Session Management
Description
User and application sessions are subject to defined management controls: sessions time out after a defined period of inactivity, concurrent session limits are enforced where appropriate, and session identifiers are protected against fixation and hijacking. Re-authentication is required after sensitive operations or extended inactivity.
Rationale
Unmanaged sessions allow attackers to hijack abandoned authenticated sessions. Session controls reduce the window of opportunity for session-based attacks.
Applicability (9 profiles)
164.312(a)(2)(iii) asks for the session to be terminated after a predetermined period of inactivity, which is a stronger act than locking the endpoint screen.
Framework Mappings (10)
| HIPAA-164.312.a.2.iii | Automatic Logoff | full |
| 8.5 | Secure authentication | informative |
| NIS2-CIR-11.6 | Authentication | informative |
| AC-10 | Concurrent Session Control | full |
| AC-11 | Device Lock | informative |
| AC-12 | Session Termination | full |
| AC-2(5) | Account Management | Inactivity Logout | partial |
| IA-11 | Re-authentication | full |
| SC-10 | Network Disconnect | full |
| SC-23 | Session Authenticity | full |
Evidence (2)
Application and IdP session management configuration showing idle timeout, absolute session lifetime, and re-authentication settings.
Example: Okta session policy export or application-level session configuration (e.g. express-session or Django SESSION_COOKIE_AGE settings in a config file, or Okta admin GET /api/v1/policies?type=OKTA_SIGN_ON) showing idle timeout ≤ policy limit, max session lifetime, and re-authentication triggers.
Test: Query the IdP session policy and a sample of application session configurations. Verify: (1) idle timeout is set to a value ≤ the policy maximum (commonly 15–30 minutes for sensitive systems), (2) an absolute maximum session lifetime is enforced, (3) re-authentication is required after the idle timeout or before sensitive operations as defined in policy, (4) concurrent session limits are configured where the platform supports it.
Application security scan or DAST report confirming that session identifiers are protected against fixation, are invalidated on logout, and are not exposed in URLs.
Example: OWASP ZAP, Burp Suite, or equivalent DAST scan report for the production application showing no high/critical findings for CWE-384 (Session Fixation), CWE-613 (Insufficient Session Expiration), or CWE-598 (Use of GET Request Method with Sensitive Query Strings).
Test: Review the most recent DAST or security scan report covering the production application. Verify: (1) report was run against the current production or pre-production build, (2) no open high/critical findings relate to session management vulnerabilities, (3) any medium findings have a documented risk acceptance or remediation ticket with a target date.
Questions (3)
Are session management controls enforced at system level?
Controls must be enforced at the system level, not left to the end user to configure. Session identifiers must not appear in URLs and must be invalidated upon logout.
What is the maximum idle session timeout configured for users accessing production systems?
Options run from strongest to weakest. Fifteen to thirty minutes is the expected range for production and administrative systems. A timeout above 60 minutes, or none at all, is a finding wherever the session reaches sensitive data.
Which session management controls are enforced on production systems?
Options run from the most commonly enforced to the least. An idle timeout with no absolute lifetime behind it leaves a session that is kept alive by activity running indefinitely.