AC-10: Concurrent Session Control

AC-10 requires you to set and enforce a maximum number of simultaneous (concurrent) sessions per defined subject (typically a user account, role, or account type) and to keep evidence that the limit is consistently applied across your environment. Operationalize it by defining the scope and thresholds, configuring technical controls in your identity stack, and testing that excess sessions are blocked or handled as designed. ¹

Key takeaways:

• Define “for each ___” and the numeric session limit as explicit, testable parameters in your access control standard. ²
• Enforce the limit in the systems that issue sessions (IdP/SSO, VPN, VDI, PAM, key apps), not only in policy. ¹
• Retain configuration proofs plus repeatable test results that show what happens when the limit is exceeded. ¹

AC-10: Concurrent Session Control is one of those “simple on paper, messy in production” requirements. The text is short, but implementation breaks if you do not define two things precisely: what a “session” means in your environment, and which identity object the limit applies to (individual user, privileged account, service account, shared admin, contractor role, customer support persona, etc.). If those parameters stay vague, you end up with controls that auditors cannot test and engineers cannot enforce consistently.

For most organizations aligned to NIST SP 800-53 Rev. 5, AC-10 shows up during assessments of identity and access management, privileged access management, remote access, and high-risk applications. The fastest path is to treat it as a measurable control: a declared maximum, a technical enforcement point, and a recurring test. Your goal is not to eliminate multi-device work. Your goal is to prevent uncontrolled session sprawl that increases account takeover blast radius, complicates termination, and hides anomalous access patterns.

This page translates the ac-10: concurrent session control requirement into concrete configuration steps, evidence to retain, and the audit questions you will get.

Regulatory text

Requirement (verbatim excerpt): “Limit the number of concurrent sessions for each {{ insert: param, ac-10_odp.01 }} to {{ insert: param, ac-10_odp.02 }}.” ²

What the operator must do:

1. Fill in the open parameters for your environment:
   • ac-10_odp.01: the “each ___” subject (for example: each user account, privileged account, or account type).
   • ac-10_odp.02: the maximum concurrent sessions allowed for that subject.
2. Implement technical enforcement so systems prevent (or deterministically handle) additional sessions beyond the maximum.
3. Produce testable evidence that the limit exists, is applied, and remains effective over time. ¹

Plain-English interpretation (what AC-10 really means)

AC-10 requires a cap on how many active logins a single account can have at the same time. If the cap is exceeded, the system must respond in a predictable way (commonly: deny the new session, or terminate an older session based on a defined rule). “Concurrent” is the key word: this is about simultaneous active sessions, not total logins per day.

Why auditors care: unlimited parallel sessions make it easier for an attacker (or insider) to keep access after discovery, and harder for you to see what “normal” looks like for a given account. It also creates operational ambiguity during incident response: you cannot confidently isolate a compromised account if it can maintain multiple live footholds.

Who it applies to

Entity scope (typical):

• Federal information systems and organizations adopting NIST SP 800-53 Rev. 5. ¹
• Contractors and third parties handling federal data in systems where NIST SP 800-53 controls are contractually flowed down. ¹

Operational scope (where it shows up):

• Identity provider (IdP) / single sign-on (SSO) session issuance
• Privileged access management (PAM) sessions (vault logins, privileged session manager connections)
• Remote access (VPN, ZTNA, VDI)
• Administrative consoles (cloud consoles, hypervisors, network device management)
• High-risk business apps (finance admin, HR admin, production change tools)

Accounts to prioritize:

• Privileged users (admins, break-glass accounts)
• Shared accounts (ideally eliminated, but still common)
• Contractor accounts and time-bounded access roles
• Service accounts (often excluded from interactive session controls, but you must document that choice)

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

Step 1: Define the control parameters (make AC-10 testable)

Create a short “AC-10 standard” entry (or add to your Access Control Standard) with:

• Session definition: what counts as a session for each enforcement point (IdP web session, VPN tunnel, VDI connection, PAM checkout session).
• Subject definition (ac-10_odp.01): per individual user account, per privileged account, or per account type (recommended: define tiers).
• Maximums (ac-10_odp.02): the cap per tier.
• Exceed behavior: deny new session, force re-auth, or terminate oldest session. Pick one per system and document it.
• Exceptions: service accounts, non-interactive tokens, monitored jump boxes, emergency accounts; include approval path and expiry.

Deliverable: a one-page standard that an engineer can implement and an auditor can test. ¹

Step 2: Build a system-by-system enforcement matrix

Create a table and treat it as your implementation backbone:

System / Access path	Issues sessions?	Enforces max concurrent?	Setting location	Default behavior on exceed	Evidence to capture
IdP / SSO	Yes	Yes/No	Admin console policy	Deny or kick prior	Screenshot/export + test
VPN / ZTNA	Yes	Yes/No	Gateway policy	Deny new tunnel	Config + logs
PAM	Yes	Yes/No	PAM policy	Block new session	Policy export + recording
VDI	Yes	Yes/No	Broker policy	Limit per user	Policy + test
Cloud console	Yes	Often No	N/A	N/A	Compensating control

This matrix prevents a common failure mode: you “set a limit” in the IdP, but VPN and PAM still allow parallel sessions. AC-10 is assessed at the system boundary, so you need a defensible story per access path. ¹

Step 3: Implement enforcement where sessions originate

Practical implementation patterns:

• IdP-enforced session caps: If your IdP supports session concurrency controls, make it the primary enforcement point for SSO apps. Confirm behavior for mobile and desktop clients.
• VPN/ZTNA per-user tunnel limits: Configure per-user or per-group tunnel concurrency. If your VPN supports “disconnect existing session,” document the chosen rule.
• PAM session governance: Limit concurrent vault logins and privileged session manager connections for admin accounts. This is usually the cleanest place to show strong AC-10 posture for privileged access.
• Application-level controls: For apps that maintain their own sessions outside SSO, configure in-app concurrency limits (or document why not possible and implement compensating monitoring).

Where enforcement is not technically feasible, document:

• Why it cannot be enforced,
• What compensating controls you use (short session lifetime, re-auth prompts, stronger anomaly detection, rapid revoke), and
• How you test those compensating controls. Keep this tightly scoped; auditors will press here. ¹

Step 4: Test like an assessor (prove fail-closed behavior)

Run repeatable tests per enforcement point:

1. Start a session as the test user.
2. Start a second session from a different browser/device/IP.
3. Attempt a third session beyond your configured cap.
4. Record: timestamp, user, systems touched, and the system’s response (deny, terminate oldest, prompt).
5. Save supporting artifacts (screenshots, logs, IdP events, VPN logs).

A strong AC-10 evidence package includes both configuration and observed behavior. ¹

Step 5: Operationalize (change control + monitoring + exceptions)

• Put AC-10 settings under change management. Record approvals for changes to concurrency limits.
• Add exception workflow with an expiry date and periodic review.
• Monitor for indicators that your control is drifting: policy disabled, new access path added (new VPN, new IdP app), or new privileged platform rolled out without concurrency caps.

If you use Daydream to manage controls, map AC-10 to a named control owner, a written procedure, and recurring evidence tasks so the evidence is collected the same way each cycle. This directly addresses the common gap of “we implemented it, but can’t prove it.” ²

Required evidence and artifacts to retain

Keep evidence that answers three questions: What did you set? Where is it enforced? Does it work?

Minimum evidence set:

• AC-10 standard / procedure with defined parameters (subject + maximum).
• System enforcement matrix (table) showing coverage across access paths.
• Configuration exports or screenshots for:
  • IdP/SSO session policies,
  • VPN/ZTNA user/group policies,
  • PAM concurrency policies,
  • Any critical app settings.
• Test results showing attempts beyond the maximum and the resulting system behavior.
• Exception register (who, why, expiry, approval).
• Change tickets for any policy modifications.

Retention period is organization-defined; align it to your broader audit evidence retention practice. ¹

Common exam/audit questions and hangups

Expect these and pre-answer them in your evidence:

• “What does ‘each’ mean in your implementation?” Show your defined subject (user vs account type). ²
• “What is the maximum number of concurrent sessions?” State the number per tier and show the setting. ²
• “Where is this enforced?” Point to the enforcement matrix and configs.
• “What happens when the limit is exceeded?” Show test artifacts.
• “How do you handle admins and break-glass access?” Show tiering and exceptions.
• “Do contractors and third-party support accounts follow the same limits?” Show group policy coverage and exception approvals.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only control. Writing “users are limited to X sessions” without a technical enforcement point fails in practice. Fix: tie AC-10 to IdP/VPN/PAM settings and keep exports. ¹
2. One system configured, others ignored. SSO might have caps, but VPN and PAM do not. Fix: maintain the enforcement matrix and review it during architecture changes.
3. No definition of “session.” Web session cookies, VPN tunnels, VDI connections, and API tokens get mixed together. Fix: define session type per system boundary and keep it consistent with how the system logs events.
4. Unlimited privileged concurrency. Admins often end up exempt “for convenience.” Fix: tiered limits with explicit exceptions, short expiry, and compensating controls.
5. Exceptions that never expire. Fix: require expiry dates and periodic review of the exception register.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat AC-10 as an assessment-driven control rather than a commonly cited standalone enforcement hook. The risk is still concrete: uncontrolled concurrent sessions increase the persistence options for compromised credentials and complicate containment, especially for privileged accounts and remote access pathways. ¹

Practical 30/60/90-day execution plan

First 30 days: Define and scope

• Assign a control owner for AC-10 and document responsibilities (policy, implementation coordination, evidence).
• Publish AC-10 parameters: subject definition and maximums, including privileged tiers. ²
• Build the enforcement matrix for your top access paths (IdP, VPN/ZTNA, PAM, VDI, cloud admin).
• Identify gaps where enforcement is not supported; draft compensating controls and an exception approach.

Next 60 days: Implement and prove

• Configure concurrency limits in IdP/SSO, VPN/ZTNA, PAM, and VDI where supported.
• Standardize exceed behavior per system and document it.
• Execute test cases for each enforcement point; collect logs/screenshots and store them in your evidence repository.
• Formalize the exception register and approval workflow (include expiry and reviewer).

By 90 days: Operationalize and make it repeatable

• Add AC-10 checks to onboarding for new apps and new remote access paths.
• Put key policy objects under change control and set recurring evidence collection.
• Run a “privileged account concurrency” review: confirm admin paths are covered and exceptions are justified.
• In Daydream, track AC-10 as a control with scheduled evidence tasks (config export + test results) to reduce scramble during assessments. ¹

Frequently Asked Questions

Does AC-10 mean one session per user, always?

No. AC-10 requires you to set and enforce a limit, but the limit is an organization-defined parameter. You must explicitly define the subject (“for each ___”) and the maximum, then prove enforcement. ²

What counts as a “concurrent session”?

Define it per system boundary: an IdP browser session, a VPN tunnel, a VDI connection, or a PAM-managed privileged session can each be a “session.” Your definition must match what you can configure and observe in logs. ¹

We allow multiple devices (laptop + phone). Can we still meet AC-10?

Yes, if your declared maximum permits that behavior and the system enforces it. Document the rationale and test that the next session beyond the maximum is blocked or handled as specified. ¹

What about service accounts and API tokens?

AC-10 focuses on concurrent sessions, which commonly map to interactive access. If you exclude service accounts or non-interactive tokens, document the exception criteria and apply compensating controls appropriate for that access type. ¹

If a system cannot enforce concurrency limits, do we fail AC-10?

Not automatically, but you need a defensible approach: document the technical constraint, apply compensating controls, and keep evidence that the risk is managed for that system’s access path. Expect scrutiny for privileged and remote access. ¹

What evidence is strongest for auditors?

Pair configuration evidence (policy export or screenshots) with test evidence (attempts beyond the limit plus system response in logs). Also keep an exception register with approvals and expirations. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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