Quality, Expert-Derived Cybersecurity Documentation To Keep Organizations Secure, Compliant & Resilient  |  Got Questions? +1-307-241-8740
ComplianceForge

How Do I Implement NIST 800-171 R3 03.01.11 Session Termination?

NIST 800-171 R3 03.01.11 Session Termination at a Glance

  • Family: 03.01 Access Control (AC)
  • Requirement ID: 03.01.11 Session Termination
  • Assessment Objectives (AOs): Two (2) total, including the one (1) Organization-Defined Parameters (ODPs) below and one (1) determination statements
  • Organization-Defined Parameters (ODPs): One (1), specified by the Department of Defense (DoD) for the Defense Industrial Base (DIB)
  • Source NIST 800-53 R5 Control: AC-12
  • NIST 800-171 R3 Kill Chain Phase: Phase 12, Secure Baseline Configurations (SBC)

Session Termination ends a user's logical session automatically when defined conditions or trigger events occur. It is easy to confuse with Device Lock (03.01.10) and with Network Disconnect (03.13.09), but it is distinct from both. A device lock is a temporary hold for a user who intends to return, and a network disconnect drops the communications session. Session Termination (03.01.11) ends the logical session itself, which ends the user's access, without necessarily terminating the underlying network connection. Per the NIST discussion, a logical session begins whenever a user (or a process acting on behalf of a user) accesses a system, and terminating it ends the associated system processes except those the user created to continue after the session ends.

A common difficulty with this requirement is confusing it with an inactivity screen lock. The requirement is not about locking a screen, it is about tearing down the session so the user has to start over. It is also entirely parameter-driven: the whole requirement hinges on the conditions or trigger events you define, and for Department of Defense (DoD) contractors those conditions are specified. If you never defined the trigger events, there is nothing for the system to act on and nothing for an assessor to check.

Where things stand for companies facing the transition from NIST 800-171 R2 to R3:

  • The National Institute of Standards and Technology (NIST) withdrew R2 on May 14, 2024, the same day R3 was published. The withdrawal notice states that R2 "has been withdrawn (archived), and is provided solely for historical purposes," so it will never receive another correction or clarification from NIST.
  • R2 remains the contractual standard for the Department of Defense (DoD) and the Defense Industrial Base (DIB). Cybersecurity Maturity Model Certification (CMMC) assessments reference it directly: per Title 32 of the Code of Federal Regulations (CFR), section 170.14(c)(3), "the security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2."
  • The rulemaking points the other direction. The proposed Controlled Unclassified Information (CUI) rule for the Federal Acquisition Regulation (FAR), published June 23, 2026 as part of the Revolutionary FAR Overhaul, would apply CUI safeguarding requirements government wide rather than only to DoD contracts, and it sets the baseline at R3. That rule is not final, and DoD has separately signaled an interim rule to move CMMC to R3.

What Does NIST 800-171 R3 03.01.11 Actually Require?

The following is reproduced verbatim from NIST 800-171 R3, requirement 03.01.11 Session Termination. Only the formatting has been adjusted for readability. This is a single statement with no lettered parts:

  • Terminate a user session automatically after [Assignment: organization-defined conditions or trigger events requiring session disconnect].

The source control is AC-12 from NIST 800-53. The single bracketed assignment is the Organization-Defined Parameter (ODP): the conditions or trigger events that require the session to end. Per the NIST discussion, this addresses user-initiated logical sessions rather than the network connections covered by 03.13.09, and conditions can include organization-defined periods of user inactivity, time-of-day restrictions on system use, and targeted responses to certain types of incidents. You can read the requirement directly at NIST 800-171 R3, 03.01.11 (p. 14).

What Are the Organization-Defined Parameters (ODPs) Associated with NIST 800-171 R3 03.01.11?

One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.

The value below comes from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.

  • ODP[01] (DoD memo identifier 03.01.11). conditions or trigger events that require session disconnect are defined. DoD Position: a specified duration (maximum of 24 hours) of inactivity, misbehavior (end the session due to an attempted policy violation), and maintenance (terminate sessions to prevent issues with an upgrade or service outage).

The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.

What Are the Assessment Objectives (AOs) For NIST 800-171 R3 03.01.11?

NIST 800-171A R3 breaks 03.01.11 into two (2) assessment objectives: one (1) Organization-Defined Parameter (ODP) and one (1) determination statement. These AOs are:

  • A.03.01.11.ODP[01]: conditions or trigger events that require session disconnect are defined.
  • A.03.01.11: a user session is terminated automatically after <A.03.01.11.ODP[01]: conditions or trigger events>.

The ODP is the whole game here. Until the conditions or trigger events are defined (ODP[01]), the determination statement (the automatic termination) has nothing to enforce. If you are a DoD contractor, the conditions are not open. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, the conditions are a specified duration of inactivity (a maximum of twenty-four (24) hours), misbehavior (ending the session on an attempted policy violation), and maintenance (terminating sessions to prevent issues with an upgrade or service outage). The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.01.11 (p. 16).

Assessment Methods and Objects for NIST 800-171 R3 03.01.11

Examine: access control policy and procedures; procedures for session termination; system design documentation; system configuration settings; list of conditions or trigger events requiring session disconnect; system audit records; system security plan.

Interview: personnel with information security responsibilities; system developers; system administrators.

Test: automated mechanisms for implementing user session termination.

How Does NIST 800-171 R3 03.01.11 Map From NIST 800-171 R2?

03.01.11 maps from NIST 800-171 R2 requirement 3.1.11 (terminate a user session automatically after a defined condition):

  • A.03.01.11.ODP[01] maps directly to R2 3.1.11[a] (conditions requiring a user session to terminate are defined).
  • A.03.01.11 maps directly to R2 3.1.11[b] (a user session is automatically terminated after any of the defined conditions).

Mapped against the two (2) AOs, both (2) are direct (minimal effort), with no net-new AOs and none with no mapping. This is a clean carry-forward. The concept, the intent, and the source control (AC-12) are unchanged. The only real change for a transitioning organization is confirming that your defined conditions still hold, and for DoD work, that they match the specified conditions rather than a single inactivity timeout you may have used under R2.

How Does NIST 800-171 R3 03.01.11 Map to NIST 800-53 R5 and the SCF?

Source Control in NIST 800-53 R5:

  • AC-12

Secure Controls Framework (SCF) Crosswalk

Organizations running a single control set across multiple frameworks can satisfy 03.01.11 through the following SCF controls:

  • CFG-04 Secure Baseline Configurations
  • CFG-04.5 Session Termination

The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.

Common Pitfalls with NIST 800-171 R3 03.01.11

The following are issues teams may encounter rather than certainties. They are about the definition and the boundaries with related controls, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:

  • The conditions are the requirement. A.03.01.11.ODP[01] requires that you define the conditions or trigger events. For DoD work that means inactivity of at most twenty-four (24) hours, misbehavior, and maintenance, not a single timeout. If the conditions are undefined, there is nothing to assess.
  • Termination is not a lock. Session Termination ends the session and the user's access. Do not satisfy it with the Device Lock (03.01.10) screen lock, which only holds the session temporarily.
  • Logical session, not network session. Per the NIST discussion, this addresses logical sessions, while network connection teardown is 03.13.09. A control that only drops network connections may not end the logical session.
  • Mind the processes that survive. Per the NIST discussion, termination ends associated system processes except those the user created to continue after the session ends. Confirm your implementation actually ends the session rather than leaving an orphaned interactive session.

What Is Reasonable Evidence For NIST 800-171 R3 03.01.11?

Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.01.11 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.01.11 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.

  • E-AST-12 Secure Baseline Configurations Reviews. A review process to ensure secure baseline configurations (sbc) are current and applicable (e.g., system configuration settings and associated documentation).
  • E-AST-13 Secure Baseline Configurations - Cloud-Based Services. Secure baseline configurations for all deployed types of cloud-based services or applications.
  • E-AST-14 Secure Baseline Configurations - Databases. Secure baseline configurations for all deployed types of databases.
  • E-AST-15 Secure Baseline Configurations - Embedded Technologies. Secure baseline configurations for all deployed types of embedded technologies.
  • E-AST-16 Secure Baseline Configurations - Major Applications. Secure baseline configurations for all deployed types of major applications.
  • E-AST-17 Secure Baseline Configurations - Minor Applications. Secure baseline configurations for all deployed types of minor applications.
  • E-AST-18 Secure Baseline Configurations - Mobile Devices. Secure baseline configurations for all deployed types of mobile devices.
  • E-AST-19 Secure Baseline Configurations - Network Devices. Secure baseline configurations for all deployed types of network devices.
  • E-AST-20 Secure Baseline Configurations - Server Class Systems. Secure baseline configurations for all deployed types of server-class operating systems.
  • E-AST-21 Secure Baseline Configurations - Workstation Class Systems. Secure baseline configurations for all deployed types of workstation-class operating systems.

Alongside these, keep the System Security Plan (SSP) narrative for 03.01.11 recording the ODP values you adopted.

Timeline Considerations for NIST 800-171 R3 03.01.11

With both AOs mapping directly and nothing net new, 03.01.11 is a light lift once the conditions are defined. A realistic sequence:

  1. Define the conditions or trigger events (A.03.01.11.ODP[01]). For DoD contracts, adopt inactivity of at most twenty-four (24) hours, misbehavior, and maintenance. For non-DoD scopes, define and document your own.
  2. Configure automatic session termination so it fires on those conditions (A.03.01.11).
  3. Confirm the boundary with Device Lock (03.01.10) and Network Disconnect (03.13.09) so each control is covered by the right mechanism.
  4. Collect evidence for both (2) AOs, including the defined conditions and configuration showing automatic termination.

Frequently Asked Questions About NIST 800-171 R3 03.01.11

What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.01.11? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.01.11: a specified duration (maximum of 24 hours) of inactivity, misbehavior (end the session due to an attempted policy violation), and maintenance (terminate sessions to prevent issues with an upgrade or service outage).

How many assessment objectives does NIST 800-171 R3 03.01.11 have? NIST 800-171A R3 breaks 03.01.11 into two (2) assessment objectives: one (1) Organization-Defined Parameters (ODPs) and one (1) determination statements. An assessor works through each one separately, so each needs its own evidence.

Which NIST 800-53 R5 control does NIST 800-171 R3 03.01.11 come from? AC-12.

Where does NIST 800-171 R3 03.01.11 sit in the NIST 800-171 R3 Kill Chain? Phase 12, Secure Baseline Configurations (SBC). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.

Bottom Line on NIST 800-171 R3 03.01.11

03.01.11 Session Termination automatically ends a user's logical session when defined conditions or trigger events occur. It maps directly from R2 3.1.11 with both assessment objectives transitioning directly, so there is no net-new work. The recurring problem is confusing it with a screen lock or a network disconnect and never defining the trigger conditions. Define the conditions (for DoD work, inactivity up to twenty-four hours, misbehavior, and maintenance), configure automatic termination, and keep the definitions and configuration as evidence.

Authoritative sources:

Authoritative sources:

This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.