AC-10 Concurrent session control: requirements and evidence

What AC-10 concurrent session control requires and why assessors check it

If your system is in the high baseline, AC-10 asks you to cap how many concurrent sessions each account or account type can hold, and to set that cap to a number you choose and can justify. The control requires the system to limit the number of concurrent sessions for each organization-defined account or account type to an organization-defined number. Two parameters, AC-10_ODP[01] and AC-10_ODP[02] in SP 800-53A, are yours to set: which accounts are covered and what the ceiling is. In SP 800-53B Release 5.2.0, AC-10 is selected for the high baseline but not for the privacy baseline, and it has no control enhancements, so the work is one decision set and one implementation rather than a stack of optional add-ons. The reason the control exists is practical. An administrator account or a sensitive application account that can be signed in from many places at once is a credential that can be shared, copied or stolen and then used in parallel with the legitimate user, with no obvious sign of it. A session cap limits how far that exposure can spread. It also forces a question that many organizations have not answered in writing: how many simultaneous sessions does a privileged administrator really need, and who is allowed to hold more than one.

This is harder than it looks because the number and the account types are judgment calls the organization must make and defend. A cap set too low breaks legitimate work, such as a support engineer working across two consoles or an automated job that opens its own session. A cap set too high, or applied to no account type at all, leaves the parallel-session risk in place. Shared administrative accounts, which some environments still use for break-glass or service work, usually force the hardest discussion, because a per-account cap may then be the only limit that matters. Before you configure anything, confirm three things with your risk owner and system owners: which account types are in scope, what ceiling each type gets and the reasoning behind it, and what happens when a session limit is reached. Whether the system refuses the new session, terminates the oldest one or alerts someone is also a choice the control leaves to you. Record all of this in the system security plan so an assessor can trace each value back to a decision.

Which accounts, systems and teams AC-10 applies to

AC-10 is only as precise as the population it covers. The scope comes from the system security plan, and the main scoping decision is which account types receive a session limit and what that limit is. The cards below cover the account types, systems, and third-party and shared access that an assessor will expect you to have decided and documented.

Administrator accounts

Privileged administrators are the usual starting point because a single unmanaged administrator session can change configuration across the whole boundary. Decide whether administrators may hold one session or a small defined number, and whether elevated sessions count separately from ordinary sessions. Check that administrator accounts on operating systems, hypervisors, databases and security tools are all in the same account type, so the limit cannot be bypassed by logging in through a less-restricted console.

Service and non-interactive accounts

Service accounts, scheduled jobs and integration accounts often authenticate from many hosts at once, so a session cap applied without thought can break production. Confirm which of these accounts hold interactive sessions at all, and treat those that do as a separate account type with its own organization-defined number. Record the reasoning in the system security plan so an assessor can see why non-interactive accounts are excluded or handled differently.

Sensitive application users

Business applications that process regulated data, such as payment, health or case management systems, are where concurrent logins can expose the most information. Identify which applications sit inside the authorization boundary and which user groups may hold several simultaneous sessions. Where an identity provider brokers sign-in, confirm whether the session limit is enforced by the identity layer or by each application, because the answer determines where the evidence lives.

Systems inside the authorization boundary

Scope AC-10 by system, not by team. Every component inside the authorization boundary that accepts interactive logins needs a stated position: enforced, inherited from a shared service, or not applicable with a reason. Remote desktop gateways, bastion hosts, web consoles and directory services are frequently missed because they sit outside the application team's view. Compare the boundary diagram against your list of login points before the assessment starts.

Third-party and vendor access

Contractors and managed service providers often hold accounts on in-scope systems and may open more sessions than an internal user would. Decide whether vendor accounts fall under the same limits, a stricter limit, or a separate agreement that the provider must enforce. Where a provider controls the login path, document the contractual or technical measure that holds them to the number your system security plan states.

Shared and break-glass accounts

Shared accounts and emergency break-glass credentials are high-risk because several people can use them and their sessions are hard to attribute. Decide whether these accounts are permitted at all, and if they are, set a limit that matches their emergency purpose. Confirm who holds the credential, how its use is recorded, and what happens to any open session once the emergency ends, since assessors often ask for this path specifically.

How a session limit is enforced in practice

A concurrent session cap is rarely enforced in one place by default. In practice the limit has to be placed at a specific enforcement point: the identity provider that issues sessions, the application that holds session state, or an access gateway or proxy that sits in front of the application. Each point counts sessions differently, and the choice determines which accounts and account types the limit can actually reach. An assessor testing AC-10 will want to see which component counts sessions, what it counts (per user, per role, per application or per device), and what happens when the number is exceeded. Those answers belong in the system design documentation, because a limit that exists only in an administrator's memory or a vendor brochure cannot be examined or reproduced.

Identity providers can centralize sign-in for many applications. authentik, for example, acts as an identity provider through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate authentication to it. That delegation does not by itself mean authentik caps how many sessions one account may hold across those applications, since session issuance and session lifetime can be configured differently per application. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, which issues tickets rather than browser sessions, so a cap on interactive logins on those hosts may need to be set in the operating system, PAM or the access tooling instead. Ask each vendor, in writing, whether its platform can enforce a per-account or per-account-type concurrent session cap, and at which layer. This is not established in the facts supplied for this page, so treat it as an open question until the product documentation and a test in your own environment confirm it.

Practical next steps are to map every administrator and sensitive application to its enforcement point, record the limit and the account types it applies to in the system security plan and design documents, and test it. A reasonable test is to open the permitted number of sessions with one test account, confirm the next attempt is refused or the oldest session is ended according to your stated rule, and capture the configuration and logs as evidence. If a limit cannot be enforced at the identity provider for a given application, document the compensating gateway or application setting and the residual risk. Your implementation partner can prepare these configurations and records, but the organization owns the chosen limit and the decision to accept any gap.

How an assessor tests session limits under AC-10

SP 800-53A gives AC-10 a single determination statement, which an assessor tests through examine, interview and test methods. The cards below follow that sequence, from the documents an assessor reads first to the live mechanism that enforces the limit.

The one determination statement

AC-10 has one determination statement in SP 800-53A Rev. 5, and it asks whether the limit on concurrent sessions is in place for each organization-defined account or account type. The assessor's job is to confirm that the two organization-defined parameters, the account types and the session numbers, have actually been set. Before testing anything, check that both values are written down and that they match what the system enforces.

Examine the policy and procedures

The examine method starts with the access control policy and the procedures addressing concurrent session control. Assessors look for a stated rule that names which accounts are limited, such as administrators or accounts with access to sensitive applications, and the number allowed. A policy that says only "limit sessions" without those values gives the assessor nothing to test.

Examine design and configuration evidence

Assessors examine system design documentation, system configuration settings and associated documentation, and the system security plan. They compare these documents with each other: the design should show where the session cap lives, the configuration should show the number, and the security plan should describe the same account types. Gaps between these documents are often the first finding raised.

Interview administrators and developers

Interview objects for AC-10 include system and network administrators and system developers. Administrators explain how the limit is applied in day-to-day operations, including what happens when a session limit is reached. Developers explain how the limit is built into the application or identity layer. Where answers differ, the assessor will ask for records that settle the question.

Test the mechanism that enforces the limit

The test method examines the mechanisms that implement the access control policy for concurrent session control. In practice, the assessor opens more sessions than the limit allows for a test account of each type and checks whether the extra session is refused or the oldest one is ended, as the organization defined. The test should run against the production-equivalent configuration, not a lab build with different settings.

Common findings to prevent

Three findings recur. Limits are defined in policy but not enforced by any mechanism. Account types referenced in the limit are not defined in the account management records. No evidence exists that anyone tested the limit after it was set. Each one can be closed with a configuration record, a list of account types and a dated test result kept with the assessment evidence.

Implementing an AC-10 session cap, step by step

This sequence turns the AC-10 requirement into a documented, configured and tested session limit that an assessor can trace from policy to system setting. Each step produces an artifact the organization can hand to its assessor and keep current as the system changes.

Define the organization-defined parameters
AC-10 leaves two values to the organization: which accounts or account types the limit covers, and the maximum number of concurrent sessions for each. Assign these with the system owner and the security lead, listing administrators, privileged service accounts, standard users and any sensitive application separately, because a single number rarely fits every group. The output is a parameter decision record that names each account type and its numeric limit. The step is done when every account type in the system has an explicit value and nothing is left to the platform default.
Document the rationale for each limit
Write down why each number was chosen, referencing the system's risk categorization, the roles that hold each account type, and any operational needs such as shift coverage or automated jobs that open sessions. Assessors look for reasoning they can follow, not just a figure. Store the rationale with the parameter decision record and have the risk owner approve it. The output is a signed rationale that explains each value and names the people who accepted the residual risk of higher limits.
Identify the enforcement points
Map every place a session can be created for the covered accounts: the identity provider, the directory and single sign-on service, the application login, administrative consoles, SSH or remote desktop gateways and API token issuance where applicable. A limit enforced at one entry point but not another leaves a gap. For open-source identity components, confirm which protocol and provider types issue sessions and whether the component can count concurrent sessions per account. The output is an enforcement point inventory that lists each entry point, the component that enforces the limit and any entry point where enforcement is not possible.
Configure the limits at each enforcement point
Apply the approved numbers in each enforcement point's configuration, using the vendor or project documentation for the exact setting names. Where an identity provider delegates sign-in to applications, decide whether the cap lives in the identity layer, the application or both, and record that decision. Capture the configuration as a baseline so changes are traceable. The output is a configuration baseline with the file, policy or setting names, the values applied, the date applied and the person who applied them. Confirm each setting against the current product version in your environment.
Test the limits against the rule
Test each enforcement point by opening sessions up to the limit and then attempting one more, using test accounts that match each account type. Confirm that the extra session is refused or that the oldest session is ended, whichever behavior the parameter decision record specifies, and that the result is logged. Repeat the test for each entry point in the inventory. The output is a test record with the account type, entry point, session count attempted, expected result, observed result and tester name. Retain failed tests with their remediation.
Record the settings in the system security plan
Describe the session cap in the system security plan under AC-10, including the account types covered, the numeric values, the enforcement points, the mechanism at each point and the link to the configuration baseline and test records. Keep the description consistent with what the systems actually do, because an assessor will compare them. The output is an updated AC-10 implementation statement that a reviewer can check against the baseline and test results without asking the operator to explain it.
Set a review trigger
Define the events that reopen the parameters: a change to the identity architecture, a new sensitive application, a change in the risk categorization, a product upgrade that alters session handling, a finding from an assessment or a change in the staff roles that hold each account type. Assign an owner for watching these triggers and state where the review outcome is recorded. The output is a documented review trigger list tied to the parameter decision record. Confirm your organization's review cadence against its own policy, since NIST leaves the frequency to the organization.

Evidence that satisfies AC-10 and how to keep it current

An assessor testing AC-10 looks for a chain of evidence: a policy that sets the rule, documented parameter values that fill in the organization-defined blanks, configuration that enforces them, and test results that prove a session beyond the limit is refused or ended. The cards below cover each artifact and the routine that keeps it accurate between assessments.

Access control policy and procedures

The policy should state that concurrent sessions are capped, for which account types, and who owns the cap. The procedures section should name the steps for setting, changing and checking the limit. Assessors examine this section first because the policy is the source the rest of the evidence must match. Check that the wording on concurrent sessions matches the values in the configuration, not a generic statement about session management.

Documented parameter values

AC-10 has two organization-defined parameters: the account or account type to which the limit applies, and the number of concurrent sessions allowed. Record both values in a single register that names each account type, its limit and the approver. Assessors compare this register against the configuration. A value that appears in the policy but not in the system is a common finding, so keep the register as the reference point for every other artifact.

Configuration exports showing the cap

Export the live settings from the identity provider, session store, or application that enforces the limit, and keep them dated and tied to a system identifier. For a self-hosted identity platform such as authentik, this means the provider or policy settings that govern sessions for each group. Note the platform version beside the export, because session behavior can change between releases. Confirm with the vendor which setting controls concurrency for each application, since not every product offers a per-account session cap.

Test records for refused or ended sessions

Assessors test the mechanism, so the file should show what happened when the limit was exceeded. Record the test account, the number of sessions opened, the session refused or terminated, and the time of the attempt. Run the test against each account type in the register, not only the most privileged one. Store the raw output with the test date, tester and build or configuration version, so the result can be reproduced at the next assessment.

System security plan entry

The system security plan should describe how AC-10 is implemented in this specific system: the account types covered, the limit values, the enforcing component and the evidence location. Where a shared service enforces the limit for several applications, the plan should state the inheritance relationship and which party maintains it. Keep the entry consistent with the parameter register so that a reviewer can trace one value from the plan to the configuration to the test.

Change records for limit adjustments

Every change to a session limit should carry a ticket with the requester, the business reason, the approver, the old and new values, and the implementation date. Link each ticket to the updated parameter register and to a fresh configuration export. Review these records on a fixed schedule to confirm that no limit changed without approval. Assessors often sample changes, so a gap between the register and the ticket history will be visible quickly.

What meeting AC-10 costs in money and effort

This table lists the cost components of meeting AC-10 and shows who is paid for each, whether it is one-time or recurring, and what drives it up or down. No price or duration is stated because none is supplied for this control, so use the drivers and quote questions to compare written proposals. Start with the number of account types and systems in scope, since that drives most other rows.

Cost component	One-time or recurring	Who is paid or who bears the effort	Main cost drivers and what to ask for in a quote
Tooling or licenses for session limits	Recurring if commercial	Software vendor or identity platform licensor	Commercial identity or privileged access tools may charge per user or per session. Self-hosted open-source identity providers such as authentik (MIT) can remove license spend, but ask the partner to state the support and upgrade cost separately.
Engineering time to configure session caps	One-time, with later changes	Implementation partner or internal platform team	Number of account types, applications and identity sources. Ask for the configuration work per application, the defined limits per account type and who records the organization-defined values.
Testing that limits are enforced	One-time, repeated after major changes	Internal engineers or implementation partner	Number of systems that need a test case and whether tests cover administrators, service accounts and sensitive applications. Ask whether test evidence is delivered in the quote.
Evidence upkeep	Recurring	Organization compliance and security staff	How often configuration exports, session policy records and the security plan are refreshed, and how many systems change. Ask how evidence is versioned and who signs off.
Policy and procedure maintenance	Recurring, usually annual or on change	Organization owners of the access control policy	Number of policy owners and the review cycle. Ask who writes and approves the session limit rules and how exceptions are recorded.
External testing or review	Recurring or per engagement	Independent security testing provider	Scope of the test, including whether session limits are tested on web, API and administrative interfaces. Ask for the written scope and deliverables before work starts.
Auditor or assessor sampling	Per assessment cycle	Independent assessor or auditor, paid by the organization	Number of account types and systems sampled, and the depth of interviews and test methods. Ask the assessor to confirm sample sizes in writing before fieldwork.
Exception handling for legacy or vendor systems	Recurring while exceptions exist	Organization and vendor of the legacy system	Number of systems that cannot enforce a cap natively. Ask how compensating controls are documented and reviewed.

Who owns AC-10 and what a partner or auditor does

The organization owns AC-10 in full. Its leadership decides which accounts or account types are limited, what number applies to each, and how exceptions are approved, because SP 800-53 leaves both the account types and the number as organization-defined parameters. The in-house team also owns the access control policy and procedures that describe the limit, and it answers for the system security plan that records how the control is met.

Parameter decisions: Set the account types (for example, administrators or sensitive application users) and the maximum number of concurrent sessions for each.
Policy and procedures: Write and maintain the access control policy and the procedures that describe how session limits are configured, reviewed and changed.
Configuration ownership: Keep the identity provider, application and operating system settings that enforce the limit under change control.
Exception handling: Approve, document and periodically revisit any account allowed to exceed the limit.
Evidence custody: Retain configuration exports, session logs and approvals so they can be produced on request.

Before engaging anyone, confirm internally which parameter values were chosen and who signed them off, since no outside party can make those decisions for you.

Where organizations fall short on session limits

AC-10 looks simple on paper: cap concurrent sessions per account or account type. In practice, the limit usually breaks at the edges, in undefined account types, federated applications, shared administrator logins and parameter values nobody revisits. The gaps below are the ones assessors most often find when they test session limits.

Account types never defined

AC-10 asks the organization to set the limit for each account or account type it defines, so a limit can only exist where those types are named. Many organizations apply a single global number, or set limits for administrators but never classify service accounts, break-glass accounts or contractor accounts. Check that every account type in your account management records has an explicit session limit, or a documented reason it has none.

Limits missing in federated applications

A session cap configured in the identity provider does not automatically apply inside every application that trusts it. Applications that keep their own session state, or that accept long-lived tokens, can allow more sessions than the policy states. Map each sensitive application to the place where its sessions are actually counted, for example by reviewing the provider settings used by authentik or FreeIPA, and confirm the application honors them.

Shared administrator accounts

A single administrator login used by several engineers can defeat any per-account cap, because each person may hold a session under the same identity. The count then reflects the shared credential rather than the people using it. Pair the limit with individual privileged accounts and confirm that the concurrent session count for each privileged account matches the number of people authorized to use it.

Session limits set but not enforced

Some platforms store a maximum session value that is never checked at login, or they enforce it only for new browser sessions while API tokens remain valid. A setting that exists in a configuration file is not evidence that the system refuses the extra session. Test the behavior directly: open sessions up to the limit, attempt one more, and record whether the system refuses it and logs the event.

No test evidence for limits

Assessors examine the policy, interview administrators and test the mechanisms that implement AC-10, so a documented limit with no test record leaves the control open. Keep dated test results showing each account type, the configured number and the observed refusal. Store those results with the system security plan so the evidence can be reproduced at the next assessment.

Parameter values never reviewed

AC-10 requires the organization to define the account types and the number for each. Those organization-defined values are often chosen during initial setup and then left unchanged as staff, applications and risk change. Assign an owner to the two parameter values, record the rationale for each number and review them when the system boundary, user population or threat picture changes.

Questions buyers ask about AC-10

How much effort does meeting AC-10 usually take?

The effort depends less on the control text than on how many account types, applications and administrative paths need a session cap. AC-10 asks the system to limit concurrent sessions for each account or account type to a number the organization defines, so the work is mostly deciding those values and configuring the identity provider, operating system, bastion or application to enforce them. Effort rises when sessions are spread across many systems with different capabilities, when some applications cannot enforce a limit natively, and when the team must document exceptions. Ask any implementation partner to break its quote into inventory, configuration, testing and evidence collection, so you can see which parts scale with your environment.

How long does AC-10 preparation take for a typical scope?

Duration depends on how many systems carry the control and how much of the session behavior is already known. A narrow scope, such as administrator sessions on one platform, moves faster than an enterprise where each application needs its own limit, its own test and its own evidence. NIST does not set implementation timelines for SP 800-53; those are left to the agency or the authorizing body under OMB Circular A-130. Ask for a written schedule tied to a fixed scope, and confirm which dependencies, such as change windows or application vendor responses, could move the dates.

What does the client team need to provide for AC-10?

The client team owns the control, so it has to supply the decisions and access that an implementer cannot make alone. Typical inputs include the list of account types that need limits, the numeric limits the organization approves, the identity and access architecture, read access to system configuration, and a named owner who can accept or reject exceptions. Your security team also needs to confirm which concurrent session behavior is required for high-impact systems, since AC-10 is selected for the high baseline in SP 800-53B. Agree these inputs in the statement of work so delays are visible early.

Can we implement AC-10 in-house without outside help?

Yes, an internal team can implement AC-10 if it has the skills to configure session limits in its identity provider, platforms and applications and to test them. The control itself is short, with no control enhancements in SP 800-53 Release 5.2.0, so the difficulty lies in coverage rather than in the wording. Teams often bring in outside help when they lack hands-on experience with a specific platform, need a test plan that matches the assessment procedure, or want an independent review before an assessor arrives. Whichever route you take, the organization keeps ownership of the control and its decisions.

What will an assessor request to test AC-10?

SP 800-53A Rev. 5 gives AC-10 one determination statement and uses the examine, interview and test methods. In practice, an assessor will examine the access control policy, the procedures for concurrent session control, system design documentation, configuration settings and the system security plan. They will interview system and network administrators and developers about how limits are applied, and they will test the mechanisms that enforce the limits, usually by trying to open more sessions than allowed and recording what happens. Prepare a current configuration export, the approved limit values and a repeatable test record for each account type.

Does DeployOpen issue the AC-10 assessment or certify our compliance?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but only an independent assessor or certification body issues findings, reports or certificates. For AC-10, DeployOpen can help configure session limits on self-hosted platforms inside your own infrastructure, document the settings and organize the evidence an assessor will request. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask the assessor you plan to use which evidence format and test records they expect before the work begins.

Which open-source tools can help enforce session limits?

Identity providers can often delegate sign-in and carry session policy for the applications behind them. authentik, under the MIT license, acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to it. FreeIPA, under GPL-3.0-or-later, provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Confirm for each platform whether it can cap concurrent sessions itself or whether the limit must be enforced elsewhere, such as at a proxy or bastion, since neither tool removes the need to test the result.

Where to read the AC-10 text and assessment procedure

Start with the NIST CPRT entry for AC-10 in SP 800-53 Release 5.2.0, because it shows the control statement as NIST publishes it and lets you check the organization-defined parameters before you write anything into a system security plan. The control asks the system to limit concurrent sessions for each organization-defined account or account type to an organization-defined number, so the two parameters, AC-10_ODP[01] and AC-10_ODP[02], are the decisions that make the control testable. Use the CPRT catalog entry for AC-10 to read the text and related controls, then confirm the release number on the page header so your documentation cites the same version your assessor uses.

The OSCAL catalog is the machine-readable source for the same control and for the SP 800-53A assessment procedure. In the usnistgov/oscal-content repository, the SP 800-53 Rev. 5.2.0 catalog JSON holds AC-10 with its parameters, and the assessment objects for the determination statement sit alongside it. Search for the AC-10 identifier, read the parameter entries, and export them into your compliance tooling so each parameter value can be tracked against a named account type. Note that the catalog labels controls with leading zeros in some outputs, so match on the identifier format your tooling uses.

The baseline profiles tell you where AC-10 applies. The SP 800-53B profiles for low, moderate, high and privacy baselines live in the same repository folder, and AC-10 is selected for the high baseline only. Open the high profile to confirm the selection before you scope it, and open the privacy profile to confirm it is absent there. If your system is categorized at a lower impact level, the control is not required by baseline, but a documented decision to adopt it is still useful evidence. Ask your assessor which profile version they will test against, because a system categorized against an earlier release may need a different reference.

How DeployOpen prepares AC-10 evidence

DeployOpen works on AC-10 as part of a written, fixed scope inside your own infrastructure. We prepare the session limit settings, the identity configuration and the evidence an assessor will examine, while your organization keeps ownership of the control and the independent assessor issues any findings.

How we scope

Agree which account types and sensitive applications need a concurrent session cap, such as administrators and high-impact systems.
Record the organization-defined account types and session numbers in writing before any configuration work starts.
Confirm which systems fall under the high baseline and which ones your organization is tailoring away from it.

How we build

Configure session limits in the identity provider and applications where the platform supports them, after confirming each capability with the vendor.
Where authentication is delegated, set session limits in the identity layer, such as authentik or FreeIPA, and test each application path.
Document the configuration settings so assessors can compare the stated limits against the system configuration.

How we hand over

Deliver the concurrent session settings, configuration exports and system design notes that map to the AC-10 assessment objects.
Provide test records showing that a session beyond the defined limit is refused or terminated, with logs of the attempt.
Hand over the documentation for your system security plan so your team and assessor can review the control without DeployOpen present.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer to keep session settings correct after changes.
Ask your assessor which evidence they expect for AC-10 before scoping, so the handover matches their test methods.