AC-17(9): Disconnect or Disable Access

AC-17(9): disconnect or disable access requirement is a remote access safety control: if you detect misuse, compromise, or simply need to rapidly reduce exposure, you must be able to terminate remote access quickly and reliably. This is an operations requirement disguised as a security statement. Assessors will look for “capability,” meaning a technical mechanism that works under real conditions, not just language in a policy.

For a CCO, GRC lead, or security compliance owner, the fastest path is to (1) enumerate every remote access entry point, (2) pick an explicit disconnect/disable time objective your organization can meet, and (3) implement and test session termination and account disablement workflows across identity, network, and application layers. The control also has third-party implications: contractors and managed service providers often have privileged remote access paths, and those are the paths you need to be able to shut down without waiting on the third party.

This page gives requirement-level implementation guidance you can hand to engineering and operations teams, plus the evidence set you should retain for audits and assessments mapped to NIST SP 800-53 Rev. 5. ¹

Regulatory text

Control statement (verbatim): “Provide the capability to disconnect or disable remote access to the system within {{ insert: param, ac-17.09_odp }}.” ²

Operator interpretation of the text

• “Provide the capability” means a working technical mechanism exists and is available when needed, including after-hours and during incidents.
• “Disconnect or disable remote access” covers two related actions:
  • Disconnect: terminate active remote sessions (force logoff, drop tunnels, revoke tokens, kill VDI sessions).
  • Disable: prevent new remote sessions (disable user/group, block remote access policy, disable VPN profile, disable remote access gateway).
• “Within the organization-defined time period (ODP)” means you must define a time target and then meet it consistently. The control is not satisfied until the time objective is explicitly documented and can be evidenced.

Plain-English requirement

You must be able to quickly shut off remote access to the system—both current sessions and future connections—within a defined maximum time, using methods your team can execute reliably during real events.

Who it applies to

Entity scope

• Federal information systems and contractor systems that handle federal data where NIST SP 800-53 is the governing control framework. ¹

Operational scope (what “remote access” usually includes) Treat remote access as a set of technical paths, not a single tool:

• VPN concentrators and client VPN profiles
• ZTNA / SDP gateways
• Bastion/jump hosts (SSH/RDP gateways)
• VDI / DaaS session brokers
• Remote admin tools used by IT/OT (including “break glass” tools)
• Cloud provider access paths (console access and federation that can reach the system)
• Third-party remote access (MSPs, incident response firms, support vendors)

If any of these can reach the system boundary, AC-17(9) expects you can shut them down promptly.

What you actually need to do (step-by-step)

Step 1 — Set your organization-defined disconnect/disable time objective (ODP)

1. Pick a single measurable objective (example format: “Remote access can be disconnected or disabled within X minutes of authorization by the incident commander or on-call security lead.”).
2. Define the authorization trigger: who can order the disconnect (IR lead, SOC manager, on-call SRE) and under what conditions (suspected credential theft, confirmed malware, third-party compromise, policy violation).
3. Document exceptions: If certain remote access cannot be terminated instantly (legacy OT, safety constraints), document compensating controls and the bounded process.

Deliverable: a short standard in your remote access policy/standard or IR runbook that names the ODP and the decision authority.

Step 2 — Inventory every remote access path to the system

Build a “remote access register” (a table is enough) with:

• Entry point (VPN, ZTNA app connector, bastion host, VDI, cloud console)
• Owning team
• Control plane (IdP, firewall, VPN admin console, EDR, PAM)
• How to disconnect active sessions
• How to disable new sessions
• Evidence/log source

Practical tip: include third-party paths explicitly (MSP VPN accounts, vendor support jump boxes). These are often missed and are high-risk during incidents.

Step 3 — Implement technical disconnect capability (active session termination)

For each remote access path, implement at least one direct session termination mechanism:

• VPN/ZTNA: admin command/API to drop sessions by user/device; revoke device posture or certificate; block source IP at gateway.
• VDI: force logoff from broker; disable pool entitlement; kill session.
• Bastion/jump host: terminate SSH/RDP sessions; disable access group; rotate/expire ephemeral credentials.
• Cloud console access: revoke active sessions in IdP; disable federation role assignment; invalidate tokens where supported.

Control design goal: termination should not depend on the end user “logging out.”

Step 4 — Implement disable capability (prevent new remote connections)

Layer controls so disabling is fast and reliable:

• Identity layer: disable the user; remove from remote-access groups; require re-auth with step-up MFA.
• PAM layer (if used): disable checkout, disable remote admin entitlements, expire privileged session approvals.
• Network/application layer: disable VPN profile; remove ZTNA policy; block at firewall; disable inbound remote admin ports at security group level.

Design goal: a small number of operators can cut off remote access even if one control plane is degraded.

Step 5 — Make the action operational (runbooks + access)

Create an “Emergency Remote Access Shutdown” runbook:

• Preconditions (what signals justify action)
• Approval and communication steps (security leadership, IT ops, impacted business owner)
• Exact commands/screens per tool
• Rollback plan (how to restore access safely)
• Post-action validation checklist (confirm sessions dropped; confirm new logins blocked)

Also ensure on-call staff have the needed admin rights through a controlled, audited mechanism (often through PAM “break glass” with logging).

Step 6 — Test the control and retain proof

Test two scenarios for each remote access path:

• Disconnect test: start a session, then force-terminate it; verify it ends.
• Disable test: block new remote sessions; verify login attempts fail as expected.

Run tests on a recurring schedule you can sustain. Keep test artifacts (see next section).

Step 7 — Tie in third-party offboarding and incident response

• Ensure third-party remote access can be disabled unilaterally by you (not “email the vendor and wait”).
• Add AC-17(9) steps to incident response playbooks so it becomes a default containment option.

Required evidence and artifacts to retain

Maintain an assessor-ready evidence packet mapped to AC-17(9):

• Remote access policy/standard stating the disconnect/disable time objective (ODP) and authority.
• Remote access register listing every remote access path and the termination method.
• Runbook(s) for emergency remote access shutdown, including tool-specific steps.
• Screenshots or exports of configuration showing the ability to:
  • terminate sessions (admin capability)
  • disable access (group/policy toggles, VPN disablement)
• Logs demonstrating:
  • session termination events
  • access disabled events
  • admin actions (who executed, when)
• Test records (tickets, change records, tabletop notes, evidence of a live test in lower environments where appropriate).
• Incident tickets where remote access was actually disabled/disconnected, if applicable, with timestamps to show alignment to your ODP.

If you use Daydream for control management, map AC-17(9) to a named control owner, a written procedure, and a recurring evidence list so evidence collection is predictable rather than incident-driven.

Common exam/audit questions and hangups

Assessors commonly ask:

• “What is your organization-defined time period for disconnecting or disabling remote access, and where is it documented?” ²
• “Show me you can terminate an active remote session right now.”
• “Which remote access methods are in scope for this system boundary?”
• “How do you disable third-party remote access quickly?”
• “Who can execute the shutdown, and how is that access controlled and audited?”
• “Show test evidence and logs for the last cycle.”

Hangups that delay audits:

• ODP exists informally but is not written.
• Evidence is “we could do it,” not “we did it in a test and here are the logs.”
• Only VPN is covered; ZTNA, VDI, and cloud console access are ignored.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Defining “disable access” as “disable the account” only.
   Fix: include session termination. A compromised session can persist after account disablement in some architectures.

2. Mistake: No single owner for remote access kill-switch actions.
   Fix: name a primary owner (Security Ops) and an alternate (IT Ops on-call), with a documented escalation path.

3. Mistake: Third-party access requires third-party action.
   Fix: contract and implement access so you can disable the account, revoke federation, or block network paths without waiting.

4. Mistake: Control works only during business hours.
   Fix: ensure on-call coverage and tested “break glass” admin access with auditing.

5. Mistake: ODP is unrealistic or undefined.
   Fix: choose an objective you can meet with current tooling, then ratchet down later after improving automation and centralization.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific NIST enhancement, so treat this as an assessment and authorization readiness issue rather than a case-law-driven requirement. The practical risk is straightforward: if remote credentials are compromised, slow termination extends attacker dwell time and increases the chance of data access, lateral movement, and destructive actions. The control is also a governance test: your incident commander must have a fast containment option that does not rely on ad hoc coordination.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and decision rights)

• Define and approve the ODP (disconnect/disable time objective) and decision authority.
• Build the remote access register for the system boundary, including third parties.
• Draft the emergency shutdown runbook with tool owners and on-call leads.
• Identify gaps where you cannot terminate sessions or disable access quickly.

By 60 days (implement kill switches per path)

• Implement session termination and disablement for each remote access path.
• Centralize control where possible (IdP groups + VPN/ZTNA policies + PAM).
• Ensure admin actions are logged and retained in your logging platform.
• Validate third-party access can be disabled by you through your control plane.

By 90 days (prove operation and make it repeatable)

• Execute at least one test per remote access path (disconnect + disable).
• Store evidence in an audit-ready repository and map it to AC-17(9) in your GRC system.
• Run a short tabletop that includes the “remote access shutdown” decision and communications.
• Convert recurring tests and evidence pulls into scheduled control operations (tickets/checklists).

Frequently Asked Questions

Does AC-17(9) require disconnecting active sessions, or is disabling new logins enough?

The text allows “disconnect or disable,” but assessors often expect you can do both in practice because “disable” may not end an already-established session. Implement a way to drop active sessions and a way to prevent new connections so you can choose the right containment action.

What counts as “remote access” for AC-17(9)?

Any method that allows a user or third party to access the system from outside the security boundary. Include VPN, ZTNA, VDI, bastion hosts, and cloud console/federated access paths if they can reach the system.

How do we handle third-party remote access (MSP/support vendors)?

Design access so you can disable it yourself through your IdP, PAM, VPN/ZTNA policy, or network controls. If the only shutdown path is “ask the third party,” you do not have a dependable capability.

Where should the organization-defined time period (ODP) live?

Put it in a controlled document that operators will actually use: a remote access standard and your incident response containment runbook. The key is that it’s approved, measurable, and tied to an execution procedure. ²

What evidence is strongest for audits?

Time-stamped logs showing an admin terminated a remote session or disabled remote access, paired with a ticket or test record that states the objective and outcome. Screenshots of settings help, but logs and test records usually carry more weight.

Can we satisfy AC-17(9) if we only have manual steps?

Yes, if the manual steps consistently meet your defined time objective and are executable by on-call staff with audited access. Automation improves reliability, but the requirement is capability within the defined time period, not a specific automation mandate. ²

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON