What AC.L2-3.1.11 session termination requires and why it is easy to get wrong
If you are preparing a CMMC Level 2 self-assessment and 3.1.11 looks unclear, start here: the requirement asks you to define the conditions that end a user session and to make the system end sessions automatically when one of those conditions occurs. It does not ask for a locked screen. Teams often read it as a variant of screen locking, which is why the requirement gets checked off on the strength of a screensaver setting that the assessor never considers the answer. The assessment guide's examples of trigger conditions include inactivity, time of day, misbehavior such as an attempted policy violation, and maintenance, so your list should show which of these apply to your systems and why.
The two assessment objectives in NIST SP 800-171A are easy to state. First, you must define the conditions that require a session to end. Second, the system must actually terminate sessions automatically when any of those conditions occurs. An assessor will expect a written list of conditions, configuration settings that enforce them, and test evidence showing a real session ending. The difference from AC.L2-3.1.10 matters here. A locked session still holds a logged-on user, a running process and open application state, so anyone who sits down at a shared or unattended endpoint can resume it. Termination closes that path, which is why it matters most on shared workstations, kiosks, jump hosts and administrative consoles.
The requirement carries 1 point in the CMMC scoring model, so it can look like a small item to fund. That is the trap. A low weight does not make the control cheap to prove, because the evidence still has to show definitions, enforcement and testing. Confirm early which of your systems have session timeouts that only lock, which have no defined conditions at all, and which depend on a remote access gateway or identity provider to enforce termination. Any 1-point gap can still block a Conditional Level 2 position if it is not on the list of requirements that may be placed on a plan of action, so check the POA&M rules in 32 CFR 170.21 before you assume it can be deferred. The eCFR text of 32 CFR Part 170 is the place to confirm the current wording.
Which systems and sessions must end automatically
Session termination only has to cover the systems inside the CUI assessment boundary, but that boundary decides how many session types, identity paths and conditions you must configure and test. Start by mapping where CUI lives and every route a person or process uses to reach it, then set termination conditions for each system rather than assuming one setting covers everything.
Systems that hold or process CUI
Every system that stores, processes or transmits CUI is in scope for AC.L2-3.1.11, including file shares, engineering tools, databases and collaboration platforms. Document each one in the system security plan and list the session mechanism it uses. A system you leave out of the boundary without a documented reason is the first thing an assessor will question. Confirm the boundary with your scoping analysis before you write termination settings.
Console and local interactive sessions
Local logons on servers, workstations and kiosks create sessions that persist until someone ends them. Check whether the operating system is configured to disconnect idle or expired interactive logons, and whether it enforces a maximum session duration. Physical consoles in shared areas are a common gap because staff assume the screen lock is enough. Session lock hides the screen but does not end the session, so verify termination separately.
Remote shell and desktop sessions
RDP and SSH sessions into CUI systems are often long-lived, and administrators may keep them open for days. Set idle timeouts and maximum session lengths on the remote access service itself, and confirm that a disconnected session ends rather than remaining logged in. Remote access sessions are a frequent scope driver because they connect users from outside the boundary, so treat them as a priority under AC.L2-3.1.12 and AC.L2-3.1.13 as well.
Web applications, VPN and cloud consoles
Web applications, VPN gateways and cloud management consoles each hold their own session state, and a timeout in one does not always end sessions in another. Test whether closing the browser, expiring a token or reaching the inactivity limit terminates the session server side. Cloud consoles that hold administrative rights to CUI systems usually need the shortest conditions. Confirm each product's session settings in its own documentation or with the vendor.
Identity providers and single sign-on
When applications delegate sign-in to a central identity provider, session termination can happen at the provider, at each application, or both. A session that ends in the provider may still leave an application session open, and the reverse is also true. Decide which layer is authoritative for each condition, document it, and test termination across a sign-out or expiry. Platforms such as authentik and FreeIPA are common choices here, and their session behavior should be verified in your own configuration.
Third-party and managed services
Managed service providers, hosted platforms and external support tools can hold sessions into your CUI environment. Identify which of them are in scope, obtain their session termination settings in writing, and include them in your evidence. If a provider cannot show its configuration, the gap belongs in your risk assessment and possibly your plan of action. Contract language should require the provider to support the termination conditions you define.
Choosing the trigger conditions an assessor will accept
Inactivity is the trigger most organizations start with, and it is the one assessors ask about first. The written definition should state what counts as activity (for example, keyboard or mouse input, or API calls tied to a user session), how long an idle session may persist, and whether the rule applies to interactive sessions, web sessions, or both. Choosing that period is a risk decision the organization makes and documents, and the decision should be tied to the sensitivity of the CUI and the setting where the session runs. Keep in mind that session lock under AC.L2-3.1.10 is a separate control, so the inactivity rule for termination should be stated independently.
- Activity definition: Write down which events reset the idle timer and which do not, so the configuration can be tested against the text.
- Documented period: Record the chosen interval, the reasoning behind it and the approver.
- Platform enforcement: Identity providers and web applications can expire sessions after idle time. For example, authentik providers and their session settings can be reviewed for this behavior.
- Coverage check: Confirm that every application that handles CUI honors the rule, including applications that cache their own sessions.
- Test record: Keep a dated test showing an idle session ending without user action.
Before the assessment, confirm with each application owner how their session timeout interacts with the central identity provider.
Time-based termination ends sessions at defined times, such as at the end of the workday or during a scheduled window when no authorized use is expected. The condition must be written with the time zone, the affected user groups, and any exceptions, such as on-call staff or shift workers. Because the requirement ties termination to a defined condition, an assessor will expect the schedule itself to be documented and matched to the configuration. Organizations should decide whether the rule applies to every user or only to standard accounts, and whether privileged or service sessions are excluded and why.
- Schedule document: Record the schedule, time zone and the systems it covers in a single approved document.
- Exception process: Define who may approve an exception, how long it lasts and how it is logged.
- Enforcement point: Confirm whether termination happens at the identity layer, the directory, or the application, and whether a session that began before the cutoff still ends.
- Directory-based policies: FreeIPA centralizes sign-in for Linux and UNIX environments, so review whether its Kerberos and access settings can express the schedule for those hosts.
- Evidence of execution: Keep logs showing sessions ending at the scheduled time.
Confirm the schedule with the operations team, because a rule that conflicts with production support will be reversed in practice and the record will show it.
Policy violation triggers end a session when a user does something the security policy forbids, such as repeated attempts to reach a restricted function or a detected misuse pattern. The CMMC Assessment Guide lists misbehavior, such as an attempted policy violation, as an example of a condition that can trigger termination. The organization must define which behaviors qualify, so the trigger is testable. Vague wording such as suspicious activity will be hard to demonstrate, so write each condition as an observable event that a system can detect and record.
- Event catalog: List each qualifying behavior, its data source and the response it triggers.
- Detection source: Use audit records or endpoint policy results as the input, and state which one is authoritative.
- Fleet policies: Fleet policies ask devices yes or no questions through osquery, which can support a condition about endpoint state, though termination must still be wired to the session.
- Wazuh rules: Wazuh alerts can feed a response, but confirm that a termination action, not only an alert, is configured for the condition.
- Test case: Trigger each defined event in a test environment and record the session ending.
Remember that alerting alone does not terminate a session, so check each condition for an actual termination action.
Maintenance events require sessions to end before work on a system begins, such as a patch window, a reboot or a configuration change. The trigger should name the event type, who initiates it, and how users are notified and disconnected. Because maintenance often involves privileged access, the organization should decide how privileged sessions are handled and document that decision alongside the related access controls. The written condition must match what operators actually do, or the procedure will not survive an assessment.
- Trigger definition: State which maintenance actions force termination, such as a service restart or a scheduled outage.
- Notification step: Describe how users are warned and how long they have before disconnection.
- Forced termination: Confirm that the platform can end active sessions on demand, not only block new logons.
- Change record link: Tie each maintenance termination to a change ticket so the event is traceable.
- Post-maintenance check: Confirm that sessions cannot resume until the maintenance window closes.
Ask the platform team to demonstrate a forced termination during a rehearsal, and keep the record.
How an assessor tests session termination under NIST SP 800-171A
The table compares the two assessment objectives for AC.L2-3.1.11 in NIST SP 800-171A, what the assessor looks for under each, the evidence to prepare, and the findings that cause a requirement to fail. Read it as a checklist: each objective must be met with evidence in final form before the requirement is scored as MET.
| Assessment objective | What the assessor checks | Evidence to prepare | Common findings |
|---|---|---|---|
| Objective a: conditions defined | The organization has defined which conditions end a user session, such as inactivity, time of day, policy violation or maintenance. | Approved procedure naming each condition, the threshold or trigger for each, and the owner who approved it. | Conditions appear only in a policy statement with no thresholds, or the list does not match what the system actually enforces. |
| Objective a: conditions defined | The condition list covers every session type in scope, including remote and privileged sessions. | Mapping of conditions to system components, such as the identity provider, VPN gateway and application servers. | Some applications or administrative consoles have no defined condition and keep sessions open indefinitely. |
| Objective b: automatic termination | Sessions end without user action when a defined condition occurs, and the session is closed, not merely locked. | Configuration settings from the identity provider, operating system and applications showing the timeout or termination values. | Session timeout is set to lock the screen only, so the session stays alive and the user can resume it. |
| Objective b: automatic termination | The assessor triggers each condition during testing and watches the session end. | Live test results: a recorded session that is idle past the threshold and is then shown as closed, with timestamps. | Testers find that a session survives an idle period because a background process or token refresh keeps it active. |
| Objective b: automatic termination | Termination applies to every connection path that carries CUI, not only the main login page. | Inventory of session paths and the setting that governs each one. | Web applications honor the timeout, but API tokens or cached sessions remain valid after the condition occurs. |
| Supporting evidence | Audit records show that terminations happened and when. | Logs of session end events with user, time, condition and source, retained under the organization's audit policy. | No termination events are logged, so the organization cannot show the mechanism operated during the assessment period. |
| Supporting evidence | Configuration and logs agree with the documented conditions. | Side-by-side comparison of the procedure, the configuration export and a sample of termination records. | Procedure says 15 minutes but the configuration says a different value, which the assessor records as a failed objective. |
How to implement automatic session termination step by step
This sequence takes an organization from an inventory of its sessions to a documented, tested and periodically reviewed set of rules that end user sessions automatically when defined conditions occur. Each step produces an artifact an assessor can examine for AC.L2-3.1.11.
Inventory session types and systems in scope
List every system that handles CUI within the assessment boundary and the session types each one creates: interactive logons to workstations and servers, web application sessions, VPN and remote access sessions, administrative consoles, database and API sessions, and sessions on mobile devices. Note which identity provider, operating system or application owns each session. The output is a session inventory tied to the system security plan boundary, with an owner named for each row. Confirm the list with the system owners, because sessions that are missing from the inventory are the ones most often left unterminated.
Define and approve trigger conditions
For each session type, define the conditions that must end a session. The CMMC Assessment Guide Level 2 lists inactivity, time of day, misbehavior such as an attempted policy violation, and maintenance as examples. Write each condition as a measurable rule, such as the inactivity period, the cut-off time, the policy violations that count, and the maintenance events that trigger disconnect. The security or compliance owner approves the list and the system owner accepts it. The output is an approved conditions register that will be the baseline for both configuration and testing. Ask the assessor's expectations early, since SP 800-171A checks that the conditions are defined.
Configure termination in each identity layer
Set the termination rules in the layer that owns each session. Centralized identity providers such as authentik can manage sign-in to applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so session lifetime and inactivity settings may be set once for connected applications where the product supports them. Directory and single sign-on services such as FreeIPA provide Kerberos-based single sign-on for Linux and UNIX environments, where ticket lifetimes and host-level session settings apply. Configure operating system, remote access and application settings wherever the central layer does not reach. The output is a change record for each setting showing the value, the system and the approver. Confirm each product's exact configuration keys with its documentation, because capabilities differ between versions.
Test each condition and capture results
Test every approved condition on every session type in the inventory. For inactivity, leave a test session idle past the configured threshold and confirm the session ends rather than only locking. For time of day, confirm a session open at the cut-off time is terminated. For policy violations and maintenance, trigger a documented test event and observe the result. Record the test date, tester, system, condition, expected result, actual result and screenshot or log excerpt. Any failed test goes back to configuration and is retested. The output is a signed test record covering both assessment objectives in SP 800-171A, meaning the defined conditions and the automatic termination when any condition occurs.
Record and log each termination
Make sure every termination produces an audit record. Confirm that the platform writes the user, session identifier, system, time, and the condition that caused the end of the session to a central log store. Where a product does not log the trigger reason, document the compensating method, such as correlating the termination with an authentication event. Verify that the logs are protected from unauthorized change and retained according to the organization's audit policy. The output is a sample of termination log entries for each session type, saved as evidence and linked to the test records from the previous step. Ask your logging platform vendor to confirm the fields it captures for session events.
Monitor configuration drift with scanning
Use a configuration assessment tool to detect when session settings change outside the approved process. Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and can check files and running processes. Add a custom policy that checks the session timeout and inactivity values in each endpoint's configuration. Fleet policies, which are osquery queries answered yes or no per device, can show which devices pass or fail a given check on its policies page. The output is a recurring compliance report per device group that flags any endpoint outside the approved settings. Confirm that each check tests the actual enforced value rather than a file that is not read at runtime.
Review settings on a schedule
Set a recurring review of the conditions register, the configuration settings, the test records and the drift reports. The reviewer compares current settings with the approved register, checks that new systems and session types were added to the inventory, and reruns a sample of the tests. Any change to a trigger condition goes through the same approval as the original definition. The output is a dated review record signed by the system owner and the security owner, with any corrective actions tracked to closure. Agree the review frequency with your organization's governance process and your assessor, since this document sets no frequency for the requirement.
Evidence that proves sessions end automatically
Session termination is tested by examining what the organization defined, how it configured each platform, and whether terminations actually happened. The cards below cover the artifacts an assessor will ask for, and each one must be current, final and tied to the same defined conditions when the assessment takes place.
Approved termination condition definitions
Start with a written, approved list of the conditions that end a session, such as inactivity, end of the workday, policy violations and maintenance. Assessment objective 3.1.11[a] asks the organization to define these conditions, so the list must exist before any configuration evidence is considered. Each condition should name its trigger, its owner and the systems it applies to. Confirm that the approval date and version are recorded, and that the list matches the conditions shown in the system security plan.
Configuration exports for each platform
Export the actual session settings from every system in the boundary, including identity providers, directory services, remote access gateways, endpoint management and cloud consoles. Open-source identity tools such as authentik and FreeIPA hold session and timeout settings that should be captured with their configuration files and change history. An assessor will compare these exports against the approved conditions, so a setting that exists only in a vendor screenshot may not be enough. Check that each export is dated and shows the value in force at assessment time.
Test records showing a termination occurred
Configuration alone does not show that sessions end. Keep test records that trigger each defined condition in a controlled way, such as an idle session on a test account, a session outside permitted hours or a simulated policy violation, and record the time, the account, the condition and the result. Assessment objective 3.1.11[b] requires that sessions terminate automatically when a condition occurs, so each test should show the session was actually ended, not just locked. Retain the test plan and results together.
Audit log entries of terminations
Logs from the identity provider, directory, gateway and endpoint tools should record each session termination with the user, the condition that triggered it and the timestamp. Confirm that these entries are forwarded to a central log store and that the time source is consistent across systems, because an assessor will reconcile log times with test records. Wazuh and similar collectors can centralize these events. Check that log retention meets the organization's stated period and that the logs cannot be altered by ordinary administrators.
Change records for setting changes
Every change to an idle timeout, time window or termination rule should have a change record that states the reason, the approver, the before and after values, and the date applied. Configuration management evidence ties these records to the baseline, so a value that drifts without a change record is a finding. Where Wazuh Security Configuration Assessment or a similar scanner reports a deviation from the approved value, keep the scan result alongside the change record that resolved it.
System security plan entry and final versions
The system security plan should describe the defined conditions, the platforms that enforce them, and the owner responsible for each. Assessors measure a requirement as MET only when the evidence is in final form, so drafts of the plan, unsigned test reports or exports marked as work in progress will not count. Before the assessment, freeze each artifact with a version and date, and reconcile the plan against the exports and test records so that no two documents disagree on a timeout value.
How self-hosted open-source platforms enforce and evidence termination
Open-source platforms can help enforce session termination at the identity layer and show assessors what was configured, but none of them ends a session on its own judgment. The organization must first define the termination conditions, then confirm in its own environment that each application, operating system and remote access path actually ends the session when those conditions occur. Treat every tool below as a place where the behavior is set and recorded, not as proof that it works.
authentik acts as an identity provider. Applications delegate sign-in to it through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, as described in the authentik provider documentation. This matters for termination because a session that is ended at the identity provider only stops if each relying application honors that end. Confirm, application by application, whether the session lifetime, idle timeout and sign-out propagation are set centrally or inside each app. FreeIPA plays a similar role for Linux and UNIX hosts, providing single sign-on through an MIT Kerberos KDC as described on the FreeIPA project site. Kerberos ticket lifetimes are not the same as an interactive session timeout, so test what a logged-in shell does when the ticket expires.
Wazuh Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and reports failed checks with remediation advice (Wazuh documentation). Write a custom check for the timeout and session settings your organization chose, such as the shell or login configuration key on each operating system, so drift is reported. A passing Wazuh check shows the setting exists on the endpoint, not that a live session was terminated. Pair it with a test that starts an idle session and records the disconnect. Fleet policies work differently: each policy is a yes or no osquery question asked of devices, and the policies page shows which devices in each fleet pass or fail, which gives a current, device-level view for assessors. Ask the implementation partner to document the policy text, the owner who reviews failures and the date each fleet was last evaluated.
What meeting AC.L2-3.1.11 costs in money and effort
This table breaks down the cost and effort of meeting session termination, showing who is paid for each component, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request and to separate internal effort from outside spend. No dollar figures or durations are given because none are supplied for this requirement.
| Cost component | One-time or recurring | Who is paid or who spends effort | What drives it up or down |
|---|---|---|---|
| Defining termination conditions | One-time, revisited on change | Internal security and compliance staff, optionally a consultant for review | Number of systems, user populations and CUI workflows. Document conditions once per system boundary to keep it contained. |
| Configuring session termination on identity and applications | One-time, plus change work | Platform engineers or an implementation partner under a written scope | Count of applications, mix of SSO and local logins, and whether timeouts are set centrally. Central settings reduce per-app work. |
| Tooling and licenses | Mostly recurring if commercial | Software vendors, or no license fee for open-source components | Open-source options such as authentik (MIT), FreeIPA (GPL-3.0-or-later) and Wazuh (GPL-2.0-only) carry no license fee but need hosting and support staff. Confirm licensing terms with each vendor. |
| Testing and configuration evidence | Recurring, at each change and review cycle | Internal engineers, with an implementation partner if testing is scoped | Frequency of configuration changes and number of systems tested. Automated configuration checks reduce manual screenshots. |
| Evidence upkeep | Recurring | Compliance staff who keep records current and in final form | Retention of session policy versions, audit records and test results. Assessors need final-form evidence, so drafts add rework. |
| External review or consultant help | Optional, one-time or periodic | Consultant or implementation partner, paid under a written scope | Team experience with CMMC and how much preparation is handled internally. Ask for deliverables and a fixed scope in the quote. |
| Auditor sampling and assessment time | Recurring at each assessment | Certified third-party assessor (C3PAO), paid by the organization | Number of systems in the assessment boundary and how many sessions and conditions the assessor samples. Keep the boundary narrow. |
| Remediation of gaps | Variable, one-time per gap | Internal staff or a partner, plus any tool changes | Gaps found in pre-assessment review, such as missing triggers for maintenance or policy violations. Test early to find these before an assessment. |
Where organizations usually fall short on session termination
Most shortfalls on AC.L2-3.1.11 come from confusing a screen lock with termination, or from settings that were correct once and have since drifted. Each card names one gap, why it matters to an assessor, and the closure action that resolves it.
Session lock presented as termination
Many teams point to a screen lock timeout and call it session termination. A lock hides the display, but the session and its authentication state remain alive, so the requirement is not met. Check that the inactivity setting ends the session itself, then confirm this by inspecting the session table or timeout configuration on the target system. Closure: reconfigure the timeout to end the session and retest with an idle account.
Conditions missing for maintenance and policy violations
The organization has to define the conditions that end a session, and assessors check that list against the system. Inactivity is often documented while the CMMC Assessment Guide's other examples, such as time of day, misbehavior like an attempted policy violation, and maintenance, are absent. Closure: write the full trigger list in the system security plan, map each trigger to a configured rule, and record who approved the list.
Termination set on some systems only
Termination is often configured on the main application or the workstation image, while VPN concentrators, administrative consoles, cloud portals and remote desktop paths keep sessions open. Each access path that touches CUI falls within the requirement. Closure: inventory every session-creating path, including remote access, and record the termination setting for each one in a single table.
No proof of automatic termination
A setting in a policy document does not show that sessions end automatically. Assessors look for configuration output and audit records that show the mechanism ran. Without this evidence, an otherwise sound design cannot be credited. Closure: export the configuration for each system, run a timed test with an idle session, and retain the resulting log entry with a date and tester name.
Settings drifting after changes
Upgrades, identity provider migrations and new images can reset or override session lifetimes without anyone noticing. A setting that passed the last assessment may fail the next one. Closure: place the session settings under configuration management, set a baseline check that alerts on change, and repeat the idle-session test after each significant change.
Who does what: your team, a partner and the auditor
Your organization owns AC.L2-3.1.11 in full. Only you can decide which conditions end a session, such as inactivity, the end of the workday, a policy violation or scheduled maintenance, because those choices reflect your CUI handling rules and risk appetite. You also remain accountable for the system security plan that describes the behavior and for every setting that enforces it.
- Defining the trigger conditions: Write down each condition that ends a session, the value you chose for it and the reason, so an assessor can compare configuration against your stated policy.
- Approving settings: Authorize the timeout values and termination rules in your change process, and record who approved them and when.
- Owning the system security plan: Describe how each condition is enforced on each system that handles CUI, including identity providers, applications and remote access paths.
- Running the review cycle: Confirm termination still works after upgrades, new applications and changes to identity configuration.
- Holding the evidence: Keep final versions of policies, configurations and audit records. Drafts do not count toward meeting the requirement.
Before engaging anyone, confirm that a named internal owner can answer for each condition and each system in scope.
An implementation partner such as DeployOpen works inside your environment to put the chosen conditions into effect and to prepare the evidence that shows it. Work is usually scoped in writing before it starts. The partner does not decide what your conditions should be, does not sign off on the requirement, and does not issue any assessment result.
- Configuring termination: Set session limits and termination rules in identity providers, applications and remote access services, based on the conditions you approved.
- Preparing test evidence: Capture configuration exports, sample session records and audit entries that show termination occurring, then organize them for review.
- Documenting the mechanism: Draft procedures and diagrams for your review, so your staff can explain the mechanism to an assessor.
- Testing before handover: Run termination tests against each condition and report what passed, failed or needs your decision.
- Supporting upgrades: Recheck termination after platform changes if you have a support arrangement in place.
Ask any partner to state in the statement of work which artifacts it will prepare and which decisions remain yours.
The assessor is the only party that tests the requirement independently and reports a finding. For Level 2 certification, that is a C3PAO authorized or accredited by the CMMC Accreditation Body. For a self-assessment, the organization performs the assessment itself and must still hold the evidence to the standard in NIST SP 800-171A. Assessors examine and test; they do not build or document the controls for you.
- Examining objectives: Check that the conditions are defined and that sessions terminate automatically when any condition occurs.
- Testing the mechanism: Trigger or observe session termination and compare the results to your documented conditions.
- Reviewing evidence: Read configuration, procedures and audit records in their final form.
- Reporting findings: Record what was met and what was not, without advising on how to fix it.
- Maintaining independence: Assessors cannot prepare the evidence they later judge, so a partner that writes your procedures should not also be the assessor.
Confirm the assessor's independence rules with the assessor before you agree any preparation work.
Some work is well suited to a partner, and some must stay with your staff or the assessor. Outsourcing the technical configuration and evidence preparation is common. Outsourcing the decision about what your conditions should be, or the assessment itself, is not an option that preserves independence or accountability.
- Usually outsourced: Configuration of identity and application settings, evidence collection, test scripts and documentation drafts.
- Usually kept in house: Choosing inactivity periods, end-of-day rules and policy-violation triggers, plus approving them.
- Never outsourced to a preparer: The assessment and the findings.
- Cost drivers to ask about: The number of systems in scope, the number of identity providers and the amount of testing required.
- What to request in a quote: A written scope listing systems, deliverables, responsibilities and handover points.
Treat any proposal that promises a particular assessment outcome as a warning sign.
Frequently asked questions about AC.L2-3.1.11
How much effort does AC.L2-3.1.11 session termination take?
For most systems, the effort is modest in the technical work and heavier in the decisions and evidence. The requirement is worth 1 point under 32 CFR 170.24, so it is a small scoring item, but assessors still test it fully. Effort rises with the number of systems, applications and session types in scope, since each one may need its own termination setting. The main tasks are defining the conditions that end a session, configuring each system to enforce them, and collecting configuration settings and audit records that show the behavior works. Ask any partner to estimate effort from a written scope that lists your systems and identity sources.
Can we implement session termination in-house?
Yes, if your team can change configuration on every system in the assessment boundary and document the results. The work is a set of configuration changes plus a written list of termination conditions. Most of the difficulty lies in consistency: a central identity provider can enforce session rules for connected applications, but legacy systems and local accounts often need separate settings. An outside partner can prepare the systems and evidence, but only an independent assessor can judge the result. Your organization still owns the control and must be able to explain it.
How long does it take to get session termination in place?
The duration depends on how many systems need configuration and how many of them need changes to their session handling. Start by inventorying applications and identity sources, then define termination conditions, change settings, test each condition and capture evidence. Testing is often the slowest step because each trigger, such as inactivity, a time-of-day rule or a policy violation, should be exercised and recorded. Any timeline should come from a written scope, and you should confirm it against your own change-control schedule.
How does session termination differ from session lock?
Session termination ends the user's session, so the user must authenticate again to resume work. Session lock, covered by AC.L2-3.1.10, only hides the screen with a pattern-hiding display while the session remains open. The two controls are separate requirements and need separate evidence. A lock timeout does not satisfy the termination requirement, and a termination rule does not replace a lock. Your documentation should show each control with its own configuration settings and test results.
Can AC.L2-3.1.11 be placed on a POA&M?
Yes, under the stated rules. Under 32 CFR 170.21, AC.L2-3.1.11 is a 1-point requirement that is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), so it may be placed on a plan of action and milestones when the score is at least 88 of 110 (0.8) for Conditional Level 2 status. Closeout is due within 180 days. Placing it on a POA&M is a business decision that carries contract risk, so confirm the current status rules with your contracting officer and your assessor before relying on it.
How does the scoring for AC.L2-3.1.11 affect our overall CMMC score?
The requirement carries 1 point in the Level 2 scoring model in 32 CFR 170.24. Your total is calculated across all 110 Level 2 requirements, so one unmet point lowers the score by one but may still leave the total above the Conditional threshold. Because 3.1.11 is not on the exclusion list, it is one of the items you can carry on a POA&M, but the total still needs to remain at or above 88 of 110. Track the score as a whole rather than requirement by requirement, and confirm the calculation with your assessor.
What does a partner need from us to prepare session termination evidence?
A partner needs a written scope and access to the configuration that governs sessions. Provide a list of systems in the assessment boundary, the identity sources they use, existing session and inactivity settings, and any documented policies on user sessions. Also provide the team members who can approve configuration changes and the change-control process you follow. Then the partner can define the conditions, test each trigger and collect settings and audit records. Your organization keeps ownership of the control and of the final decisions.
How DeployOpen prepares session termination evidence
DeployOpen helps organizations prepare the systems, settings and records that show session termination works as the organization defined it. The organization still owns its conditions for ending sessions, and an independent assessor decides whether the requirement is met.
How we scope
- Agree in writing which systems, applications and identity providers fall inside the AC.L2-3.1.11 session termination scope.
- Record the termination conditions the organization has defined, such as inactivity, end of workday, policy violations and maintenance windows.
- Confirm with the organization which conditions it must document before work starts, since DeployOpen cannot set them for the organization.
How we build
- Configure session lifetimes and forced termination in the self-hosted identity provider, such as authentik, for each connected application.
- Set up device compliance checks with Fleet policies or Wazuh configuration assessment where a termination condition depends on endpoint state.
- Keep configuration files and settings under version control so assessors can see the state in effect at the time of review.
How we hand over
- Deliver the documented termination conditions, configuration exports and test results in a form the organization can present to its assessor.
- Document how each termination test was run, what the expected result was and what the observed result was.
- Provide a runbook that explains how staff can review, change and re-test termination settings after an update or maintenance event.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
- Re-test session termination after platform upgrades, identity provider changes or new applications join the environment.
- Confirm with your assessor and your own environment which evidence format and retention period they expect before handover.
