AC-10: Concurrent Session Control

Quick-reference card

What this control requires

AC-10 requires organizations to set a maximum number of concurrent sessions allowed for each system account and enforce that limit automatically. This control targets a specific gap. When multiple active sessions exist under a single account, security teams lose the ability to distinguish legitimate activity from unauthorized access.

In practice, organizations must define session limits at the account level, the account-type level, or globally across the system. High-privilege accounts, such as system administrators or personnel operating in sensitive domains, typically warrant stricter limits than general users. These limits should be codified in access control policy and enforced through system configuration, not left to manual oversight. The NIST SP 800-53 framework treats concurrent session control as a HIGH-baseline requirement because unmanaged sessions create a durable, low-visibility attack vector.

Where AC-10’s scope ends is as important as where it begins. It applies to concurrent sessions for individual system accounts, not to scenarios where a single person holds multiple accounts. That distinction matters for implementation because it means the enforcement mechanism operates at the account layer, not the identity layer. Organizations that conflate the two often deploy controls that miss the actual risk. A thorough NIST 800-53 compliance checklist should verify that session limits are configured per account or account type, not simply assumed from identity provider settings.

Why it matters

Unlimited concurrent sessions give attackers a structural advantage because they can operate inside a compromised account at the same time as the legitimate user, generating no displacement event and no lockout trigger. This makes detection extremely difficult through conventional monitoring.

Specifically, an attacker obtains a valid OAuth token or session cookie through a malicious Office macro (T1137), a phishing landing page that captures the token after authentication, or a browser extension that steals stored tokens (T1528). With that token, the attacker authenticates into the target system. Because the legitimate user is also actively authenticated, there is no displaced session, no failed login, and no account lockout. Both sessions coexist, and the attacker’s activity blends into normal usage patterns.

The result is persistent, low-visibility access that can last for days or weeks. The attack is especially effective against high-privilege administrative accounts and against SaaS platforms where session tokens have long expiry windows. Browser session hijacking (T1185), where an attacker injects into an authenticated browser process, is a direct exploit of this control gap. The hijacked session runs alongside the legitimate one, with the user entirely unaware. Enforcing a maximum of one active session per account forces the attacker’s token to either displace the legitimate user, triggering an unexpected logout event, or fail outright.

What attackers exploit

• Application access token theft (T1528): Attackers steal OAuth tokens or API keys stored in browsers, credential managers, or application caches to open parallel authenticated sessions that bypass traditional login controls.
• Office application startup persistence (T1137): Malicious macros embedded in Office documents capture session tokens at authentication time, granting the attacker a valid session that coexists with the user’s own.
• Browser session hijacking (T1185): Attackers inject into an already-authenticated browser process, inheriting the active session without triggering a new login event. The legitimate user sees no change in behavior.
• Long-lived session tokens on SaaS platforms: Many SaaS applications issue tokens with multi-day or multi-week expiry windows. Without concurrent session limits, a stolen token remains valid and usable alongside the original.
• Targeting privileged access accounts: Administrative accounts are the highest-value targets because a single compromised admin session can modify security configurations, create new accounts, or exfiltrate data while the legitimate admin remains logged in.

How to implement

For your organization

The most common failure mode is assuming that identity provider (IdP) settings automatically enforce concurrent session limits at the application layer. In most environments, the IdP manages authentication but delegates session management to individual applications. That means each application must be configured independently to enforce AC-10.

In practice, this means inventorying every system in scope for HIGH-baseline controls and documenting which ones support native concurrent session limits. Enterprise directory services, VPN concentrators, and remote desktop gateways typically offer built-in session controls. SaaS applications vary widely in their support, and systems that lack native enforcement may require a reverse proxy, cloud access security broker (CASB), or session management middleware to enforce the limit externally.

Where inventory ends, policy begins. Define session limits by account type. System administrator accounts and accounts with elevated privileges should be limited to one concurrent session. Standard user accounts may tolerate two or three concurrent sessions depending on operational needs, but the limit should still be explicit and documented.

In practice, this means you also need to configure a defined system action when that limit is exceeded. Common options include blocking the new session, terminating the oldest session, or prompting the user to choose which session to end. The chosen behavior should align with the organization’s operational requirements and be documented in the access control policy.

Specifically, test your enforcement by attempting to open sessions beyond the configured limit and confirming the system blocks or terminates the excess session. Capture screenshots or log entries as evidence. Review session limit configurations during each assessment cycle and after any system upgrade that could reset defaults.

The result compounds when concurrent session monitoring feeds into your security information and event management (SIEM) platform. Alerting on repeated session-limit violations can surface credential compromise or account sharing before either causes damage.

For your vendors

The most common failure mode in third-party assessments is accepting a vendor’s claim that they “support session management” without verifying that concurrent session limits are actually enforced. Many vendors implement session timeouts (which address idle sessions) but never restrict the number of simultaneous active sessions for a single account.

Specifically, ask during vendor assessments: “Does your platform enforce a maximum number of concurrent sessions per account?” Follow up with: “What is the configured limit for administrative accounts, and what action does the system take when the limit is exceeded?” These questions are distinct from general session management and should be treated as separate line items in your questionnaire.

Specifically, the distinction surfaces when reviewing evidence. A screenshot of a configuration page showing a session limit value is a starting point, but also ask for a log excerpt showing a session denied or terminated due to the limit. If the vendor cannot produce this evidence, it suggests the control is either not configured or not testable in their environment.

Where this risk concentrates is in SaaS platforms with long-lived API tokens or OAuth grants. These token-based sessions often bypass traditional session management controls entirely. Ask whether API token sessions count toward the concurrent session limit and whether the vendor has a mechanism to revoke tokens when limits are breached. Review NIST CSF third-party risk requirements for additional guidance on structuring these assessments.

In practice, the most common red flags are vendors that conflate session timeout with concurrent session control, vendors that enforce limits only at the IdP layer without application-level enforcement, and vendors that exempt API or service accounts from session limits without a documented risk acceptance.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for this control.

Related controls

• SC-23 — Session Authenticity: SC-23 protects the integrity of individual sessions by binding them to authenticated users and preventing session hijacking through token validation, while AC-10 limits the number of those authenticated sessions that can exist simultaneously.
• AC-2 — Account Management: AC-2 governs the lifecycle of system accounts, including creation, modification, and removal, and its account review processes should verify that concurrent session limits are configured for each active account type.
• AC-12 — Session Termination: AC-12 requires systems to terminate sessions after defined conditions such as inactivity timeouts, complementing AC-10 by reducing the window during which excess sessions could persist.
• AC-17 — Remote Access: AC-17 controls how users connect to systems remotely, and concurrent session limits are especially relevant for VPN and remote desktop sessions where parallel access from different locations may indicate compromise.
• AC-6 — Least Privilege: AC-6 restricts user privileges to the minimum necessary, and tighter concurrent session limits on high-privilege accounts reinforce least-privilege principles by reducing the attack surface of administrative access.
• IA-5 — Authenticator Management: IA-5 manages the credentials used to establish sessions, and strong authenticator management reduces the likelihood that stolen credentials lead to unauthorized concurrent sessions.

Frequently asked questions

What is NIST SP 800-53 AC-10

AC-10 is the NIST SP 800-53 control that requires organizations to limit the number of concurrent sessions permitted for each system account. It applies at the HIGH baseline and targets the risk created when multiple active sessions under a single account make unauthorized access indistinguishable from legitimate use. Organizations must define limits globally, by account type, or by individual account, and enforce those limits through system configuration.

What happens if AC-10 is not implemented

Without concurrent session limits, an attacker who obtains a valid session token or cookie can maintain a parallel authenticated session alongside the legitimate user indefinitely. There is no displaced session, no failed login alert, and no lockout event to trigger investigation. This gap is especially dangerous for administrative accounts and SaaS platforms with long-lived tokens, where a single stolen credential can provide weeks of undetected access.

How do you audit AC-10

Auditors assess AC-10 by comparing the documented maximum concurrent session count for each account type against the actual enforcement behavior observed in live systems. The audit typically begins with the access control policy to confirm that session limits are defined per account type, then moves to direct inspection of configuration settings in each in-scope application, directory service, and remote access gateway. The critical test is an active attempt to exceed the configured limit. The auditor opens sessions beyond the stated maximum and records whether the system blocks, terminates, or permits the excess session. Gaps between documented limits and actual enforcement are the most common finding. The OWASP Top 10 covers session management as a core web application security concern and provides a useful supplementary reference during these assessments.

How many concurrent sessions should you allow per account

The right limit depends on the account type and operational context. Administrative and high-privilege accounts should be restricted to one concurrent session to ensure that any parallel access immediately displaces the legitimate user and triggers an alert. Standard user accounts may warrant two or three concurrent sessions to accommodate legitimate multi-device usage, but the limit should be explicitly defined and enforced rather than left at a permissive default.