FutureFeed CMMC Education Series · Access Control
Access Control (AC): 3.1.11
The short version
If you’re responsible for CMMC compliance, here’s what this requirement comes down to. You need to:
- Define the conditions that should automatically end a user session: inactivity, time-of-day limits, or an automated response to certain incidents
- Configure systems to end the session when a condition is met, not just lock it
- Configure and validate those conditions across the systems and session types they are meant to protect
- Confirm the termination ends the authenticated session, not only the connection
Those four come down to two questions: are the conditions that should end a session defined, and does a session actually end on its own when one of them occurs.
If you already have those things in place, you’re well on your way. Now let’s look at what each one actually means.
In plain English
This control answers one question: what ends a session the user never closed? A condition you’ve defined, automatically.
A session lock, the last control, pauses the screen and hides it but keeps the person logged in. This one goes further: when a condition you set is met, the session actually ends, and the user is logged out and has to sign back in to keep working. You choose the triggers. Rev 2 names three kinds: a period of user inactivity, a time-of-day restriction on system use, and a targeted response to certain types of incidents.
This requirement is about authenticated user sessions, which exist in operating systems, applications, remote-access services, and other interactive environments. Rev 2 draws the line plainly: a user session can be terminated, ending that user’s access, without terminating the network session underneath it. The reverse catches people out too. Dropping a network connection does not always end the authenticated session, so confirm your configuration ends the session you meant to end.
That is also why closing a browser window or disconnecting a remote-desktop client is not the same as termination. The session can still be alive on the server, waiting for the user to come back.
When your condition is met, the session doesn’t just lock, it ends. That’s the whole idea.
You set remote sessions to terminate automatically after 30 minutes of inactivity. A contractor connects from home, works a while, then gets pulled away. When the limit is reached the session ends without anyone taking action, and to keep working they sign back in. During an incident your team may also end sessions by hand, or your tooling may revoke them automatically. Note the difference: an automated response to a defined incident condition is what this requirement asks for, while an administrator ending a session by hand is a capability worth having rather than a demonstration of automatic termination.
How to implement it
Here is the order I would work through it:
Define the conditions.
Decide what should automatically end a session: a period of inactivity, a time-of-day restriction, or an automated response to certain incidents. Rev 2 names all three.
Decide idle against absolute.
An idle timeout ends a session after a stretch of no activity. An absolute limit ends it after a set duration however busy the user has been. Either can be right, depending on the system.
Identify the session types in scope.
Operating systems, applications, and remote-access services each carry their own sessions and settings.
Configure termination, not locking.
The session has to end and require signing back in, not pause behind a lock screen.
Check the layer where the session actually lives.
Closing a browser window or dropping a remote-desktop client can leave an authenticated session alive on the server.
Validate across the systems you intended to cover.
A timeout on one remote-access system does not necessarily reach the others.
Maintain the configuration.
Revisit the conditions when systems, remote-access technology, or response procedures change.
The idea is that a session does not stay open forever just because nobody closed it.
A new stop every Tuesday and Thursday.
Our twice-weekly series breaking CMMC down one step at a time. Opt in and we’ll send each one to your inbox.
What to document and maintain
A sustainable implementation has three pieces: people who decide and maintain the conditions, technology that enforces them where the sessions live, and documentation recording what was decided.
People
- Security, who decides which conditions should end a session
- IT, who configures and maintains termination across session types
- Whoever validates that a session actually ends when a condition occurs
Tools
- Identity, operating-system, and application settings for session timeout and termination
- Remote-access gateway and remote-desktop session settings
- Incident response tooling, where an automated response ends sessions
Documents
- Your defined conditions, and which session types each one covers
- Configuration standards for each session type, and any exceptions
- An SSP description of how the requirement is implemented
The control works when the conditions are real, and meeting one ends the session on its own.
When should I work on this
Do this alongside session lock and your remote-access setup, since they are all session settings and are easiest to work through together. The inactivity condition is usually a quick setting. The incident-driven one depends on your incident response tooling, so revisit it when you build that family out.
Common challenges
Sessions only lock, never end.
Why it happens: A screen lock is set and assumed to cover this, but a lock keeps the session alive; it doesn’t terminate it.
Recommendation: Define the conditions that should end sessions in your environment, then configure and validate them across the systems and session types they are meant to protect. A timeout on one remote-access system does not necessarily reach the others.
Remote sessions stay open indefinitely.
Why it happens: VPN or remote-desktop sessions have no timeout, so a forgotten connection stays live for hours.
Recommendation: Set an inactivity termination on remote and network sessions, where an abandoned session is riskiest.
Incident termination depends on someone being available.
Why it happens: The plan for a compromised account is that somebody notices and ends the sessions by hand, which depends on who is working and how fast they see it.
Recommendation: Build the response into your tooling so a defined incident condition ends sessions automatically, and keep the manual capability for the cases automation does not cover.
What good looks like
A contractor connects to a remote-access system, works a while, and is pulled away. The inactivity condition the organization defined is reached, and the system ends the session on its own: not a lock screen, a sign-out. When they come back, they authenticate again. After hours, the time-of-day condition ends sessions still open. Nobody had to watch a clock.
An organization doing this well can usually answer yes to all of these:
For 3.1.11
- Are the conditions that should end a session automatically defined?
- Does a session end on its own, signing the user out rather than locking, when a condition occurs?
- Do the conditions reach the session types they were meant to protect, verified rather than assumed?
Good supporting practice
- Is manual termination available for the incidents your automation does not cover?
If any answer is no, that’s your next place to start.
The word in parentheses is doing the work. The requirement asks for termination that happens automatically after a condition you defined, so an administrator ending a session by hand is a useful capability rather than a demonstration of this requirement. Ending a session is also not the same as locking it, and not the same as dropping a network connection. NIST does not dictate the condition or the timing: you decide what fits, then configure and validate it across the session types you meant to cover.
How this connects to other controls
A few close relationships:
- Session lock (3.1.10): a lock pauses and hides the screen; this ends the session. A pair, but not the same action.
- Monitor and control remote access (3.1.12): ending idle or after-hours remote sessions is where this requirement pays off most clearly.
- Incident Response (3.6): Rev 2 names a targeted response to certain incidents as a condition that can trigger automatic termination, which is where this requirement and your response procedures meet.
The requirement, word for word
For your reference, the exact language from the source:
Terminate (automatically) a user session after a defined condition.
Every organization implements these controls a little differently. If you’re not sure whether your approach actually satisfies the requirement, join one of our upcoming webinars or schedule a 15 Minutes with FutureFeed session. We’d rather help you work through the question now than discover a gap later.
Sources
- NIST SP 800-171 Rev 2, Access Control (3.1)
- Related requirements: see also 3.1.10 (session lock), 3.1.12 (monitor and control remote access), and 3.6.1 (incident handling) within NIST SP 800-171 Rev 2.
