What AC-12 session termination requires and why assessors test it
AC-12 asks the system to automatically end a user's logical session once conditions the organization has defined are met or a defined trigger event occurs. If you run a moderate or high baseline system, you need an audit-ready AC-12 position: a written list of the session termination conditions, a configuration that enforces them, and records showing it works. The control is selected in the moderate and high baselines in SP 800-53B Release 5.2.0 but not in the privacy baseline. None of its three enhancements, AC-12(1) through AC-12(3), is selected in any baseline, so an assessor will test the base control and whatever parameters you set for it.
The scope is the user session, meaning the authenticated interaction between a person and an application, portal, administrative console or operating system login. That is different from SC-10, which concerns ending network connections after a period of inactivity. An application can satisfy AC-12 by expiring a web session after a defined idle period, and a network boundary can satisfy SC-10 without touching the application session at all. Confirm which control your system security plan assigns to each condition so the same timeout is not claimed twice or missed. The organization must also define the conditions itself, such as inactivity limits, maximum session age, or termination on a role change, and assessors will compare the system's behavior against that definition.
AC-12 is hard to keep true because session settings drift. Identity providers, application frameworks, reverse proxies, load balancers and administrative tools each carry their own timeout values, and a change in one layer can silently override another. Upgrades and new deployments often reset defaults. Plan a recurring check that reads the effective session settings from each component, compares them with the documented conditions, and retains the output as evidence. Tools such as Wazuh's Security Configuration Assessment can check configuration files against policy on monitored endpoints, which gives you a repeatable way to detect drift before an assessor does.
Which systems, sessions and teams fall under AC-12
AC-12 applies to every logical user session the system creates, so scoping starts with the system security plan boundary and an inventory of where sessions begin and end. The organization, not NIST, defines the conditions and trigger events that end a session, and each team that owns a session path needs to know which conditions apply to it.
Application and identity sign-in paths
Start with every place a user session is created: web applications, mobile back ends, and the identity paths that issue them. Where applications delegate sign-in to a central identity provider, such as authentik through OAuth2, OpenID Connect, SAML or LDAP, confirm whether session lifetime is set in the provider, in the application, or in both. A session that survives in the application after the provider ends it is a gap assessors will look for.
Administrative consoles and privileged sessions
Administrative consoles, cluster dashboards and database admin tools often carry the most sensitive sessions and are the ones most often left with default timeouts. List each console, who uses it, and whether it runs under the same termination conditions as user-facing applications. Privileged sessions may also need the stricter conditions your organization defines for AC-12, so document them separately in the plan.
APIs and non-interactive clients
Confirm whether API tokens, service sessions and scripted clients count as user logical sessions under your definitions. Long-lived tokens that never expire are a common scoping question. Decide which API flows are user-initiated sessions covered by AC-12 and which are governed by other controls, such as those in the IA family, and record that decision in the system security plan.
Remote and VPN sessions
Remote access sessions often sit across several components: a VPN concentrator, a bastion host and the application behind it. Termination on one layer does not guarantee termination on another. Identify which layer ends the user session and which layer ends only the network connection, since SC-10 covers network disconnect. Teams running remote access should confirm both controls are mapped separately.
Hosted and third-party components
SaaS identity services, managed databases and vendor-hosted consoles may manage sessions outside your control. Where a third party sets session lifetimes, request its documented settings and evidence, and decide whether the component sits inside the boundary or is covered by an agreement that lets you show the control is met. Ask vendors to confirm how and when they end user sessions, since you cannot test a setting you cannot see.
Teams that define conditions and own evidence
AC-12 requires the organization to define the conditions and trigger events that end a session, so security, application owners, identity engineers and the team that maintains the system security plan must agree on them. Assign one owner per session path to keep the defined conditions current, and confirm which team retains the audit records and configuration exports assessors will examine.
How an assessor tests AC-12 in practice
The examine method asks the assessor to read documents and records. For AC-12, the first thing the assessor looks for is a documented list of the conditions or trigger events that end a user session, such as inactivity, a maximum session age, or a change in the user's authentication state. The assessor then checks whether that list matches what the system is configured to do, and whether the organization has defined the conditions at all. The second thing is the system audit records. These should show that sessions were actually terminated when the defined conditions occurred, not only that the settings exist.
- Defined conditions: a written list of session termination conditions or trigger events, approved and tied to the system security plan.
- Configuration records: exported settings from the identity provider, application or session store that show the defined conditions are in force.
- Termination audit records: log entries showing sessions ended by the defined conditions, with timestamps and user or session identifiers.
- Scope statement: a clear list of which applications and session types the conditions cover.
- Exceptions: any documented exceptions with a stated reason and approval.
Before the assessment, confirm that the audit records are retained long enough to cover the assessment period and that they can be searched by session event type.
The interview method asks the assessor to talk with the people who run and build the system. For AC-12, the assessor usually interviews system and network administrators and system developers. The goal is to confirm that the people operating the system understand the termination conditions, know where they are configured, and can explain how a session ends when a condition is met. The answers should match the documents and the configuration. When they do not, the assessor will test more closely.
- Administrators: how session timeouts and maximum lifetimes are set, who can change them, and how a change is approved.
- Developers: how the application issues, refreshes and invalidates session tokens or cookies, and what happens on logout.
- Operators: how they confirm termination is working, and what they do when a session fails to end.
- Shared components: whether sessions are ended by the identity provider, a reverse proxy or the application, and who owns each layer.
- Change history: how termination settings changed over the review period and why.
Prepare a short walkthrough for each role so the answers are consistent across interviews.
The test method asks the assessor to observe the automated mechanisms that terminate sessions. Here the assessor checks that the mechanisms work as described, not only that they are documented. A typical test starts a session, lets a defined condition occur, and confirms the session is ended and the user must authenticate again. The assessor may also test logout, token revocation and behavior after a privilege change, depending on the conditions the organization defined.
- Inactivity test: start a session, stop activity, and confirm termination at the defined interval.
- Maximum lifetime test: confirm a session ends at its maximum age even when the user stays active.
- Logout test: confirm logout invalidates the session on the server, not only in the browser.
- Forced termination test: where the organization defined an administrator or policy trigger, confirm the trigger ends the session.
- Evidence capture: the test should produce logs or screenshots the assessor can keep as evidence.
Before the assessment, run these tests yourself on a non-production copy and keep the results, so the assessor sees the same behavior the organization reports.
Evidence requests and common assessor findings for AC-12
This table pairs each SP 800-53A assessment method for AC-12 with the artifact the assessor will ask for and the findings that commonly follow. Read it as a pre-assessment checklist: if an artifact cannot be produced on request, expect that method to become a finding. The main takeaway is that the defined conditions, their settings across every layer, and the termination logs must agree with one another.
| Assessment method | Artifact requested | Common assessor finding |
|---|---|---|
| Examine: list of conditions or trigger events | Documented, organization-defined list of conditions that end a user session, with the values chosen for each (for example, idle time or session age) | Conditions are referenced in the system security plan but never defined, or the values are blank, so the control cannot be tested |
| Examine: system audit records | Logs showing session terminations with timestamp, account, reason and the trigger that fired | No audit record exists for terminations, so the assessor cannot confirm the mechanism runs as designed |
| Examine: configuration of session timeouts | Exported settings from the identity provider, application frameworks, load balancers and reverse proxies showing each session limit | Timeouts set in one layer (for example, the identity provider) but not in the application or proxy, leaving sessions open longer than documented |
| Interview: system and network administrators | Named administrators who can explain how terminations are configured, changed and monitored | Administrators describe a timeout that differs from the documented value, or cannot say who approves changes to it |
| Interview: system developers | Developers who can show where session termination is coded or configured for each application | Custom applications rely on default framework behavior that was never reviewed against the defined conditions |
| Test: automated termination mechanism | Live test evidence: a session left idle or aged past the limit, showing the session is ended and the user must sign in again | Test fails to end the session, or ends only the browser view while the server-side session token remains valid |
| Test: trigger event handling | Results of a test for each defined trigger event, such as a password change or a revoked account, with the outcome recorded | Trigger events defined on paper but never tested, so termination on those events is unverified |
| Cross-check: related controls SC-10 and MA-4 | Evidence that network connection timeouts (SC-10) and nonlocal maintenance sessions (MA-4) are handled separately from user session termination | Network disconnect settings are cited as proof of AC-12, which the assessor will not accept for a user session control |
Implementing AC-12 step by step
This sequence turns the AC-12 requirement into working settings and evidence: written termination conditions, mapped enforcement points, tested configurations, recorded parameters, audit logging and a recurring review. Each step names what it produces so an assessor can follow the trail from policy to running system.
Define termination conditions and trigger events in writing
The organization owner of the system, usually the system owner with the security lead, lists every condition that must end a user session, such as inactivity, a maximum session age, a logout request, a credential change or a risk-based trigger. AC-12 leaves these values to the organization, so the decisions belong to the organization, not to the implementation partner. The output is a short session termination standard with one row per condition and an owner for each row. You know this step is done when every row has a stated trigger and a named approver.
Map each condition to its enforcement point
For each condition, record which component enforces it: the identity provider, the application, the host operating system or a reverse proxy. A single identity provider such as authentik can issue sessions to many applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS or proxy providers, so some conditions may live in the provider and others in each application. Where an application keeps its own session, the mapping must show that termination reaches it. The output is a mapping table that names the setting, the component and the owner of each. You know it is done when no condition lacks an enforcement point.
Configure session settings in each component
The implementation team sets the chosen values in each identified component and records the exact configuration keys, file names and versions used. Where Linux hosts are in scope, FreeIPA can provide single sign-on through an MIT Kerberos KDC, and its ticket lifetime settings should be checked against the standard. Changes go through the normal change process so the before and after state is recorded. The output is a configuration baseline per component. You know it is done when each mapped setting matches the standard and the change record exists.
Test each termination condition
The test team triggers every condition in a non-production copy of the environment and confirms that the user session ends, that a new login is required and that the application does not keep an active session afterward. The tests should cover at least one condition per enforcement point and the test objects that SP 800-53A names for AC-12, which are the automated mechanisms that implement session termination. Results are saved with dates, test accounts and screenshots or logs. The output is a signed test report with pass or fail for each condition. You know it is done when every failure has a fix and a retest.
Record the parameter values in the system security plan
The system owner copies the approved values, the enforcement points and the responsible roles into the system security and privacy plan for the AC-12 control. The entry should state the organization-defined conditions and trigger events in plain terms, and it should link to the configuration baseline and test report. Assessors examine this text first, so it must match what the systems actually do. The output is an updated plan section with version and approval date. You know it is done when the plan, the configuration baseline and the test report agree on every value.
Enable audit logging of session terminations
The operations team turns on logging for session starts, timeouts, logouts and administrator-forced terminations in the identity provider, applications and hosts, and forwards those records to the central log store. Wazuh can collect and analyze host logs, and its Security Configuration Assessment can check that the settings from earlier steps remain in place on monitored endpoints. The records must carry a user identifier, a time stamp and the trigger that ended the session. The output is a log source list and a sample of termination records. You know it is done when a test termination appears in the central store with all required fields.
Set a review cycle and monitor drift
The system owner sets a recurring review of the termination values, the configuration baselines and the test results, and assigns who runs it and who signs off. Fleet policies can answer yes or no questions about endpoints as osquery queries and show which devices pass or fail each policy, which helps detect drift between reviews. Any change to a condition returns the work to the earlier steps. The output is a review calendar, a review checklist and the most recent signed review. You know it is done when the first review record exists and the next review date is assigned.
AC-12 versus SC-10: which session is ending
AC-12 ends a user's logical session, while SC-10 ends network connections. The distinction matters because the two controls sit at different layers and an assessor will test each one against its own wording. AC-12 asks that the system automatically terminate a user session after organization-defined conditions or trigger events, such as inactivity or the end of a defined period. The session is the application or identity-layer relationship between a person (or process) and the system. SC-10 concerns the network connection itself and asks that it be ended after a defined period of inactivity. The SP 800-53 catalog lists SC-10 as a related control for AC-12, which signals that the two are meant to be read together but are not interchangeable.
(Illustrative example) A user signs in to an internal case management application through a reverse proxy and an identity provider. After 15 minutes without activity, the application invalidates the session token and returns the user to the sign-in page. That is the AC-12 event. The browser's underlying TCP connection to the proxy may stay open for a while longer, or be closed by the proxy under a separate idle rule, and that behavior belongs to SC-10. A reader should confirm the actual values in their own environment: the application's session lifetime, the identity provider's session settings, and the proxy's idle timeout are usually configured in three different places by three different teams.
Assessors ask for both because a session can end at one layer while the connection stays alive at another, and each layer can be left open. A single timeout setting rarely satisfies both controls, because the application session, the identity provider session, and the network connection each have their own clock, their own trigger conditions and their own evidence. Before an assessment, check that each layer's configuration is documented, that the defined conditions in AC-12 match the values actually set, and that audit records show session terminations from the application side. Ask the system administrators and developers named in the assessment procedure to walk through the settings, since that conversation often exposes the gap.
Evidence that passes an AC-12 test
An assessor testing AC-12 looks for a defined set of conditions, configuration that enforces them, and records showing the mechanism works in practice. The cards below cover the documents and records that connect those three points, and how to keep each one current between assessments.
Documented termination conditions
The organization must define the conditions and trigger events that end a user session, such as inactivity limits, absolute session lifetimes, logout requests, or changes in a user's role or privileges. Assessors examine this list first, so each condition should name the system, the user population it covers, and the owner who approved it. Check that the list matches what the identity provider and applications actually enforce, and that it is referenced from the access control procedures in the system security plan. Review it whenever a new application joins the environment.
Identity provider configuration exports
Export the session lifetime, idle timeout, and logout settings from the identity provider and from each application that keeps its own session. For authentik, these settings sit on the provider objects that applications use for OAuth2, OpenID Connect, SAML, or proxy sign-in, so export each provider rather than relying on a single global value. Store the exports with a timestamp and the commit or change reference, so the assessor can see the value in force on the test date. Confirm which settings the application honors, since an identity provider timeout does not end a session the application keeps alive.
Audit records of session terminations
Session termination events should appear in audit logs with the user, session identifier, source, time, and reason, such as idle timeout, absolute timeout, or explicit logout. Assessors sample these records to confirm that terminations occur in practice and that the reasons match the documented conditions. Confirm that the logs are forwarded to a central store the application team cannot edit, and that a query can pull all terminations for a chosen date range. Missing reason codes are a common gap, because they make it impossible to show which condition fired.
Termination test results
Keep dated test records showing that a session ends after the defined condition, with the test steps, the expected result, the observed result, and the tester's name. Run the tests against production-like environments for each application and for administrative consoles, which often use different timeout values. Include a negative case where activity keeps the session alive, so the test shows the timer resets only on real user activity. These records give the assessor a direct test result to compare against the configuration exports.
Change records for session parameters
Every change to a timeout, lifetime, or logout setting should go through the same change control as other configuration changes, with a request, an approver, the old and new values, and the date deployed. An assessor who sees a session limit raised without a record will question whether the documented condition is still the one enforced. Where the settings are kept as code or in a version-controlled configuration repository, the commit history can serve as the change record, provided it names the approver. Ask the platform team to confirm that emergency changes follow the same trail.
Periodic review records
Record a periodic review of the session termination conditions, the configuration exports, and the test results, with the reviewer, the date, the findings, and any follow-up actions. The review should compare the defined conditions against the current configuration and flag drift, such as a new application without a documented timeout. The review frequency is set by the organization in its own policy, so confirm the interval with your assessor and with the policy owner, and keep the review records in the same repository as the policy so they are easy to produce.
What meeting AC-12 costs in money and effort
This table breaks the cost of meeting AC-12 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a written scope and to ask a provider for a quote that separates setup from upkeep. No prices or durations are given because none are supplied for this control.
| Cost component | One-time or recurring | Who is paid | What drives it |
|---|---|---|---|
| Session termination tooling or licenses | Recurring where commercial | Vendor of the identity provider or session platform | Number of applications and users, and whether session policy features sit in a paid tier. Self-hosted open-source identity providers can remove this line but not the configuration work. |
| Configuring idle, absolute and logout termination per system | One-time, repeated for each new system | Internal engineers or an implementation partner | Count of applications, mix of web, SSH, RDP and API sessions, and whether each system enforces its own timeout or inherits one from a central provider. |
| Defining the organization's termination conditions and trigger events | One-time, revisited on policy change | Internal security and compliance staff | How many conditions the organization defines, such as inactivity, session age, privileged sessions and sensitive transactions. AC-12 requires these to be defined. |
| Testing that sessions actually end | One-time per system, recurring after changes | Internal testers or an external tester | Number of session types, how many browsers and clients are in use, and whether tests cover logout, timeout and forced termination from the server side. |
| Evidence collection and upkeep | Recurring | Internal compliance staff or an implementation partner | Frequency of evidence pulls, number of systems in scope, and whether configuration and audit logs are collected automatically or by hand. |
| Auditor or assessor sampling | Recurring at each assessment | Independent auditor or assessor, who issues the report | Number of systems sampled, quality of the evidence package, and how many exceptions the assessor raises. DeployOpen prepares evidence but does not issue assessment results. |
| External testing or review | Recurring, usually tied to a test cycle | Independent testing firm or internal red team | Scope of session testing, whether session hijacking and replay are included, and how often the test is repeated after major changes. |
| Ask for in any quote | Not applicable | Requesting organization | A written, scope-based quote that lists each system, each termination condition, the testing method, the evidence to deliver and which items are one-time versus retainer-based. |
Who owns AC-12 and who can help
The organization owns AC-12 in full. It decides which conditions or trigger events end a user session, such as inactivity, a maximum session age, a change in risk level or a logout request, and it records those values as organization-defined parameters in its system security and privacy plan. Accountability sits with the system owner and the security function, which must also decide how the control interacts with SC-10 network disconnect and related controls such as MA-4 and SC-23.
- Parameter decisions: Setting the session termination conditions and approving them through the risk process.
- Policy and procedure: Maintaining the access control policy and the procedures that describe how sessions end for each application class.
- Operation and monitoring: Running the systems, reviewing exceptions and acting on audit records that show session termination events.
- Assessment cooperation: Supplying configuration exports, audit records and administrator access for the assessor's examine, interview and test steps.
- Retained work: Anything the organization does not hand over in writing, which remains its responsibility by default.
Before engaging anyone, confirm internally who holds each of these roles so that the partner and auditor have a named counterpart for every session termination decision.
An implementation partner such as DeployOpen can configure the self-hosted identity, session and endpoint tooling that enforces AC-12 inside the client's own infrastructure, then document how that tooling behaves and produce the evidence an assessor will request. The partner does not decide the organization-defined parameters and does not sign off on conformance. Its output is a prepared system, a configuration record and an evidence set that the organization reviews and adopts.
- Session configuration: Setting idle and maximum session lifetimes in the identity provider and in applications that delegate sign-in to it, for example through authentik providers.
- Evidence preparation: Exporting configuration, showing termination events in audit records and writing the test scripts that the assessor can repeat.
- Endpoint checks: Building policies in tools such as Fleet or Wazuh that confirm devices and hosts run the expected settings.
- Documentation support: Drafting the procedure text for the system security and privacy plan, which the organization must approve.
- Testing support: Running security tests on the session behavior before the assessor arrives, reported as findings for the organization to fix.
Ask the partner in writing which items it configures, which it documents and which it leaves to the organization, and confirm that its work product does not include any audit report or attestation.
The independent assessor or auditor tests whether AC-12 is implemented and operating as the organization describes. SP 800-53A structures this work as one determination statement with examine, interview and test methods, using objects such as the list of trigger conditions, the audit records and the automated termination mechanisms. The assessor issues the findings and the assessment report, and that report, not a partner's work, is what carries weight with a federal authorizing official or a contracting customer.
- Independence: The assessor must not design, configure or remediate the control it tests, so the partner cannot act as the assessor for the same system.
- Test scope: The assessor selects which applications, sessions and administrators to sample and decides the test method for each.
- Interviews: The assessor speaks with system administrators and developers, as SP 800-53A lists, and records their answers.
- Report ownership: Only the assessor issues the findings. Neither the organization nor the partner can write or alter the conclusion.
- Engagement terms: Confirm the assessor's qualifications and independence through the contracting authority or the framework that requires the assessment.
Where a partner has prepared the evidence, the organization should tell the assessor who did what, so the assessor can judge how much weight the prepared evidence deserves.
Where AC-12 implementations usually fall short
AC-12 looks simple on paper: end a user session when a defined condition occurs. In practice, the gaps sit between systems, in undocumented timeout values, mismatched settings across identity and application layers, missing termination records, and configuration that shifts after changes. Each card below names one gap and the closing action an assessor would expect to see.
Timeout values live in code, not documents
Session lifetimes are often set in application code, framework defaults or a vendor console that nobody wrote down. AC-12 requires the organization to define the conditions or trigger events that end a session, and an assessor will ask where those values are recorded and who approved them. Close this gap by writing each idle and absolute timeout into the system security plan, with the owner, the value and the date it was last confirmed against the running configuration.
Identity provider and application disagree
A user may be signed out of the identity provider while the application keeps a valid session cookie, or the reverse. This happens when the identity provider and each relying application set their own lifetimes. Authentik, for example, acts as an identity provider for applications through OAuth2, OpenID Connect and SAML, so each application's session length must be checked against the provider's settings. Test a logout from one application and confirm that every other connected application also ends its session.
Termination leaves no audit trail
Many teams can show that a timeout is configured but cannot show that it fired. AC-12 assessment includes examining system audit records, so a session that ends without a logged event produces no evidence. Confirm that the identity provider or application writes session start, termination and reason fields to a central log store, and sample those records during the assessment preparation cycle. Logs that record only logons are not enough to show termination.
Privileged sessions lack defined triggers
Administrative sessions on hypervisors, databases and directory services often run longer than user sessions or never expire at all. The trigger events for these sessions must be stated explicitly, such as idle time on a jump host or completion of a privileged task. Use FreeIPA or a similar directory to set Kerberos ticket lifetimes for administrators, and document which privileged interfaces follow which rule. Assessors interview system administrators on this point, so their answers should match the written trigger list.
Settings drift after upgrades
Session timeouts are frequently reset to vendor defaults during patch cycles, container image rebuilds or migrations to new versions. Configuration baselines that were correct at go-live can change without any approved change record. Use a configuration assessment tool such as Wazuh Security Configuration Assessment, which checks endpoints against YAML policies and recommends remediation, to flag changed session settings. Record each upgrade as a change and re-verify the timeout values afterward.
Device posture ignored at session start
Sessions are sometimes long lived on endpoints that have since fallen out of compliance, such as devices missing a screen lock or running outdated software. AC-12 is about ending sessions under defined conditions, so organizations should decide whether a failing device posture is one of those conditions. Fleet policies, which are yes or no osquery questions about devices, show which endpoints are passing or failing each check. Confirm with the risk owner whether a failed check should end access or only trigger an alert, and record the decision.
Questions buyers ask about AC-12 cost, effort and scope
How much effort does AC-12 session termination take to implement?
The effort depends less on the control text than on how many systems create user sessions and how many of them already end sessions on defined conditions. AC-12 asks the system to automatically end a user session after conditions the organization defines, such as inactivity, a logout event or a change in risk. Most of the work is deciding those conditions, configuring each application or identity provider to enforce them, and collecting evidence that the settings are active. A single identity provider with a few integrated applications is a much smaller task than a estate of custom applications with their own login logic. Ask any partner to size the work by listing the systems in scope, their session mechanisms and the number of defined trigger events.
Can our internal team implement AC-12 without outside help?
Yes, if the team has the skills to configure session lifetimes in its identity and application platforms and to produce evidence for an assessor. AC-12 is not selected in the low baseline, but it is selected in the moderate and high baselines, so organizations in those scopes must meet it. The organization owns the control and its defined conditions. An implementation partner can prepare the systems, configure them and document the evidence, while an independent assessor tests the result. Internal teams usually keep ownership of the policy decisions and hand off the engineering work when they lack capacity or experience with the platforms in use.
What does the internal team need to provide for AC-12 work?
The team needs to supply the decisions and access that only the organization can provide. These include:
- Approved definitions of the conditions or trigger events that end a user session, such as inactivity periods, privileged activity or sensitive transactions
- Named owners for each application and identity provider in scope, with administrator access for configuration
- Current audit records and logs that show how sessions end, so the evidence can be reviewed
- Interviews with system administrators and developers, since the assessment method for AC-12 includes interviews
Without these inputs, any configuration will be difficult to justify to an assessor.
How long does AC-12 take to implement, and what should we confirm?
No researched duration is available for AC-12, so this page does not give one. The timeline depends on the number of systems in scope, whether session settings are already defined centrally, and how quickly the team can approve trigger conditions and test them. Ask any partner for a written, fixed-scope timeline based on your system list, and confirm the dependencies: change windows for production systems, the availability of application owners and the time needed for assessor scheduling. Session behavior should also be tested in a non-production environment before the settings reach users.
Can a partner issue the AC-12 assessment or certify our compliance?
No. A partner can prepare the systems, configure session termination and organize the evidence, but only an independent assessor or authorizing official can issue the assessment outcome. NIST describes SP 800-53 as a flexible framework implemented within an organization-wide risk management process, so the decision on whether AC-12 is satisfied rests with the organization and its assessor. DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Ask the assessor which evidence they expect for AC-12 before implementation begins.
How does AC-12 differ from SC-10 and AC-11?
AC-12 ends a user's logical session in an application or system, while SC-10 ends network connections, and AC-11 locks a device until the user authenticates again. The SP 800-53 catalog names SC-10 as a related control for AC-12, and SC-10 covers network disconnect rather than the user session itself. AC-11 device lock keeps the device protected but leaves the user's session state in place. Teams often configure all three together, but each has its own defined parameters and its own evidence, so assessors expect separate records for each. Confirm the boundaries with your assessor before mapping settings to controls.
Which open-source tools help produce AC-12 session evidence?
Identity platforms are the main source of session evidence, and their configuration is what an assessor will examine. authentik acts as an identity provider for applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications can delegate sign-in and session handling to it. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Wazuh Security Configuration Assessment and Fleet policies can check that endpoint settings match the defined conditions. Confirm each platform's session timeout and logout features in your environment, since the supplied facts do not describe them in detail.
How DeployOpen prepares AC-12 evidence
DeployOpen starts AC-12 work with a written scope that names the systems whose user sessions must end automatically, the organization-defined conditions or trigger events the client has chosen (for example, idle timeout, maximum session age, or sign-out on a privileged action), and the owner of each decision. The scope also records which applications delegate sign-in to a central identity provider and which sit outside it, because an assessor will test each system separately. Deliverables, responsibilities and the handoff date are agreed in writing before configuration begins. The client keeps ownership of the control: the policy values, the trigger list and the risk acceptance for any exceptions remain its decisions, and DeployOpen documents them rather than choosing them.
Inside the client's own cloud accounts, data centers or air-gapped network, DeployOpen configures the self-hosted tools that enforce and observe session behavior. Where applications sign in through authentik, the session lifetime and inactivity settings are applied at the provider level and tested per application. Where Linux and UNIX hosts authenticate through FreeIPA, Kerberos ticket lifetimes and host login behavior are reviewed against the documented triggers. Wazuh Security Configuration Assessment policies and Fleet policies, written as osquery queries, can check endpoint settings such as screen-lock and session-timeout configuration and report which devices pass or fail. The team confirms each of these settings against the product documentation for the versions in use, since exact option names and defaults change between releases.
For the assessor, DeployOpen assembles the material that SP 800-53A describes as examine and test objects: the list of conditions or trigger events, configuration exports, audit records showing sessions ended by the system, pass and fail history from the endpoint tooling, and a walkthrough of a test session timing out. Interviews with administrators and developers are prepared, but the people themselves answer the questions. DeployOpen does not issue audit reports, attestations or certifications. An independent assessor or certification body performs the assessment and reaches its own conclusion. Before the assessment, the client should ask its assessor which evidence formats it accepts and whether exported screenshots, configuration files or dashboard reports are sufficient.
How DeployOpen approaches AC-12 engagements
DeployOpen works on AC-12 Session termination as a fixed-scope engagement inside the client's own infrastructure. The organization owns the control and its session policy, while DeployOpen prepares the systems, configuration and evidence that an independent assessor reviews.
How we scope
- Agree in writing which applications and user session types fall within AC-12 scope before work starts.
- Record the organization-defined conditions and trigger events for session termination, with the owner who approves them.
- Confirm which identity providers, endpoints and administrative paths are included, and which are handled by other controls such as SC-10.
How we build
- Configure session lifetime, idle timeout and logout behavior in the identity provider chosen for the environment.
- Set up audit records of session start, expiry and forced termination so assessors can trace each defined trigger.
- Test automated termination against each defined condition in a staging environment before it reaches production systems.
How we hand over
- Deliver configuration exports, test results and the session termination settings the assessor will examine.
- Document the procedure for changing session parameters, including who approves changes and how they are logged.
- Walk the client's administrators through the evidence set so they can rerun the tests after upgrades.
How we support
- Offer ongoing support and upgrades as a retainer when session settings or identity components change.
- Repeat termination tests after platform upgrades so the evidence stays current with the deployed configuration.
- Confirm with the client's assessor which artifacts they need, since only the independent assessor issues findings.
