AC-17(5): Monitoring for Unauthorized Connections

AC-17(5) requires you to continuously monitor remote access pathways and the network/environment they terminate into so you can detect and respond to unauthorized remote connections (for example, rogue VPN sessions, unmanaged remote tools, or misconfigured gateways). Operationalize it by inventorying every remote access method, centralizing telemetry, alerting on “unknown or unapproved” connections, and retaining evidence that monitoring and response run in production. ¹

Key takeaways:

• You must be able to detect remote connections that are not explicitly authorized, not just authenticate approved users. ¹
• The hard part is coverage: enumerating all remote paths (vendor tools, cloud consoles, break-glass, legacy) and getting logs into one place.
• Auditors look for repeatable evidence: data sources, alerts, tickets, and review records tied to an owner and procedure.

AC-17(5): monitoring for unauthorized connections requirement is a remote access control enhancement under NIST SP 800-53 Rev. 5 that pushes you past policy statements into measurable detection. If your environment supports remote administration, remote user access, third-party support access, cloud management consoles, or site-to-site connectivity, you need a way to identify connections that should not exist and to prove you would notice them promptly in normal operations. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat AC-17(5) as a detection-and-evidence problem with clear boundaries: (1) define what counts as a “remote connection” in your environment, (2) define what “unauthorized” means in a way engineering can implement, (3) instrument the control points that can observe and block or alert, and (4) preserve evidence of alerts, investigation, and review. This page gives you requirement-level implementation guidance you can hand to IT/SecOps, plus the artifacts you need for assessment readiness against NIST SP 800-53. ²

Regulatory text

Requirement (provided excerpt): “NIST SP 800-53 control AC-17.5.” ²

Operator interpretation of what you must do: Implement monitoring designed to detect unauthorized remote connections to your information system. In practice, you need (a) defined approved remote access methods and entry points, (b) technical visibility into those entry points and adjacent network/control planes, (c) alerts or detections for connections outside the approved set, and (d) an operational response path that triages and resolves suspected unauthorized connections with retained evidence. ¹

Plain-English interpretation (what AC-17(5) is really asking)

AC-17(5) expects you to answer, quickly and with evidence:

• “How do we know if someone is remotely connected who shouldn’t be?”
• “How do we detect remote access tools or tunnels we did not approve?”
• “How do we spot misconfigurations that create unintended remote entry points?” ¹

This is not satisfied by having a VPN, MFA, or a remote access policy alone. Those are preventative controls. AC-17(5) is about monitoring and detection, which means telemetry, alerting, and response for remote connectivity that falls outside your authorized patterns.

Who it applies to (entity and operational context)

AC-17(5) is relevant anywhere you have remote access, especially:

• Federal information systems assessed against NIST SP 800-53 controls. ¹
• Contractor systems handling federal data (for example, environments supporting federal contracts where 800-53 controls are in scope). ¹

Operationally, it applies to:

• Enterprise VPN/ZTNA and remote desktop access
• Cloud admin planes (cloud console/API access, privileged remote management)
• Third-party support access (MSPs, device manufacturers, software support)
• Site-to-site tunnels and partner connections
• Remote management agents and “screen sharing” tools
• Remote access into OT/ICS enclaves if present (same monitoring concept; different tooling)

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

Use this as an implementation runbook you can assign to IT/SecOps with clear outputs.

Step 1: Set the scope and definitions (write it down)

1. Define “remote connection” for your environment (examples: VPN session, ZTNA session, SSH from the internet, RDP via gateway, cloud console session, remote support agent session, site-to-site tunnel).
2. Define “unauthorized” in implementable terms. Typical categories:
   • Remote access method not on the approved list (rogue tool/tunnel).
   • Remote connection to an unapproved destination (for example, direct-to-server bypassing the gateway).
   • Remote connection from an unapproved source (unexpected geolocation/IP ranges, unknown device identity, non-corporate IdP).
   • Remote connection outside permitted time windows for a third party, if you use time-bounded approvals.
3. Name a control owner (Security Operations or IAM tends to own; GRC governs) and document escalation paths.

Deliverable: “Remote Access Monitoring Standard” (1–3 pages) mapped to AC-17(5). ¹

Step 2: Inventory every remote access path (the success/failure point)

Create a remote access inventory with, at minimum:

• Method/type (VPN, ZTNA, RDP gateway, SSH bastion, cloud console, vendor tool)
• Entry point (FQDN/IP, gateway name, cloud service)
• AuthN source (IdP, local accounts, shared accounts prohibited/controlled)
• Logging source (where logs are produced)
• Owner (team accountable)
• Approved populations (employees, admins, specific third parties)
• Environment (prod/non-prod; sensitive enclave)

Common miss: remote access that “isn’t called remote access,” like cloud break-glass accounts, emergency vendor access, or firewall temporary rules.

Deliverable: Remote Access Inventory (spreadsheet or CMDB extract) with owners and logging status.

Step 3: Centralize monitoring telemetry (minimum viable data sources)

To detect unauthorized connections, you need telemetry from the control points where remote access happens:

Core sources

• VPN/ZTNA authentication and session logs
• Bastion/jump host logs (SSH/RDP session start/stop, source/destination)
• Remote desktop gateway logs
• Firewall/edge device logs (inbound rules, remote admin interfaces)
• IdP logs (admin logins, risky sign-in events, MFA events)
• Cloud audit logs (management plane access events)

Optional but high-value

• EDR detections for remote admin tools (RMM agents, screen sharing binaries)
• Network IDS/NDR for unusual tunnels/protocols

Route logs to your SIEM or centralized logging platform with retention aligned to your broader logging policy.

Deliverable: Data Source Register showing each remote path, its log source, and confirmation it is ingested.

Step 4: Implement detections for “unauthorized”

Build alert logic that maps to your “unauthorized” definition. Start with a small set you can operate, then expand.

High-signal detection examples:

• Remote access to administrative interfaces exposed to the internet that should be internal-only
• VPN/ZTNA sessions for disabled users, stale third-party accounts, or unexpected privilege level
• Successful remote logins from sources not in approved IP ranges (especially for admin access)
• New remote access service spun up without change approval (new public listener, new tunnel endpoint)
• New remote management agent installed or beaconing

Tie each detection to:

• Severity
• On-call/queue
• Triage steps
• Containment steps (disable account, revoke session, block IP, remove agent)
• Required ticket fields for evidence

Deliverable: Detection Catalogue for Remote Access (AC-17(5)).

Step 5: Prove response: alerts must create tickets and outcomes

Monitoring only counts if someone acts on it.

Minimum operating model:

1. Alert fires.
2. Ticket is created with timestamp, alert payload, and assignment.
3. Analyst documents triage: authorized vs unauthorized; evidence checked.
4. If unauthorized: containment + eradication + root cause (misconfig, rogue tool, compromised account).
5. Closeout includes corrective action (rule tightened, account lifecycle fix, third-party access changed).

Deliverable: Ticket samples demonstrating detection-to-resolution.

Step 6: Establish governance reviews (control performance, not just policy)

Run recurring reviews to demonstrate the control stays effective:

• Review remote access inventory for drift (new methods, decommissioned methods).
• Review alert tuning and false positives.
• Review third-party remote access approvals and expirations.
• Validate log ingestion health and gaps.

Deliverable: Review minutes or checklists with actions and owners.

Required evidence and artifacts to retain

Auditors typically want evidence that the control is designed, implemented, and operating:

Control design artifacts

• AC-17(5) control statement mapped to your environment (how you monitor for unauthorized connections) ¹
• Remote access architecture diagram(s): gateways, bastions, IdP, cloud admin access paths
• Remote Access Inventory with owners and approved methods
• Logging/SIEM architecture and data flow diagram (remote access logs to central store)
• Detection Catalogue with alert logic descriptions and runbooks

Operating effectiveness artifacts

• SIEM ingestion health reports or screenshots showing logs arriving from each remote path
• Alert samples over time (sanitized) plus associated tickets and closure notes
• Incident records for confirmed unauthorized connection attempts, if any occurred
• Evidence of periodic reviews (checklists, change approvals, meeting notes)
• Change tickets for detection tuning or remote access configuration changes

Practical tip: keep a single “AC-17(5) evidence packet” folder per review period with a short index.

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “List every remote access method and show how each is monitored.”
   Hangup: teams monitor VPN but miss cloud console, vendor tools, or site-to-site tunnels.

2. “Show an example of an alert for an unauthorized connection and the response.”
   Hangup: alerts exist but don’t generate tracked work.

3. “What is your definition of unauthorized remote access?”
   Hangup: policy language is too vague for engineering to implement.

4. “How do you ensure monitoring continues to work?”
   Hangup: no evidence of log ingestion health checks or periodic review.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Monitoring only the VPN	Unauthorized connections often bypass VPN	Include bastions, cloud audit logs, edge/firewall events, remote tools
No authoritative list of approved remote methods	You can’t label anything “unauthorized”	Maintain remote access inventory and approval process
Alerts that don’t map to a runbook	Analysts can’t triage consistently	Write detection-specific triage/containment steps
Third-party access not time-bounded or reviewed	Orphaned accounts look “authorized”	Tie third-party access to approvals and periodic review cadence
Logging gaps unnoticed	Control silently stops working	Add ingestion health checks and ownership

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is straightforward: unauthorized remote connections are a common path to data exposure, disruption, and loss of system integrity. For federal systems and contractors handling federal data, failure to detect unauthorized remote access can become an assessment finding, delay an authorization decision, or drive corrective action plans tied to contractual obligations. ¹

Practical 30/60/90-day execution plan

You asked for speed. Use this phased plan to reach an auditable baseline, then mature.

First 30 days (get to “defined and instrumented”)

• Assign control owner(s) and publish the AC-17(5) control statement. ¹
• Build the remote access inventory, including third-party paths.
• Confirm logging exists for each path; start SIEM ingestion for the highest-risk entry points.
• Draft 5–10 high-signal detections and write runbooks for each.
• Stand up ticket routing for alerts (even if initial triage is manual).

Days 31–60 (make it operational)

• Expand log ingestion coverage to remaining remote paths; document gaps with remediation dates.
• Tune detections based on false positives; add correlation (IdP + VPN + bastion).
• Run a tabletop test for “suspected unauthorized remote access” and capture artifacts (tickets, decisions, escalation).
• Implement recurring review checkpoints (inventory drift, third-party access review, ingestion health).

Days 61–90 (make it durable and auditable)

• Add monitoring for “new remote access introduced” by integrating with change management signals where possible.
• Formalize metrics that support oversight (alert volume, time-to-triage as an internal target, top causes).
• Build the AC-17(5) evidence packet template and populate it from real operations.
• If you use Daydream, map AC-17(5) to a named owner, implementation procedure, and recurring evidence artifacts so collection is repeatable each cycle. ²

Frequently Asked Questions

What counts as an “unauthorized connection” if a user has valid credentials?

Unauthorized can mean the method, path, or destination is not approved, even if credentials are valid. Define unauthorized as “outside approved remote access methods and conditions,” then implement detections against that definition. ¹

Do I need to block unauthorized connections or just monitor them?

AC-17(5) focuses on monitoring, but monitoring should feed a response that can contain and remediate. Blocking is a strong compensating measure, but the requirement you must satisfy is detection with operational follow-through. ¹

How do we handle third-party remote support access under AC-17(5)?

Put third-party access methods in the same inventory as employee access, require named accounts, log all sessions, and alert on access outside approved windows or from unexpected sources. Retain approvals and tickets to show what “authorized” means for that third party.

We have cloud-only workloads. What should we monitor?

Monitor cloud audit logs for management plane access (console/API), IdP sign-ins, and any remote administration channels into workloads (bastions, SSM-style agents, remote shells). The goal stays the same: detect access paths that were not approved. ¹

What evidence is most persuasive to an auditor?

A complete remote access inventory mapped to log sources, plus several real alert-to-ticket examples that show triage and closure. Add a short record of periodic reviews that shows you catch drift and logging failures.

How granular do alerts need to be to satisfy AC-17(5)?

Start with a small set of high-signal alerts you will reliably work, then expand. Auditors prefer a control that runs consistently over a long list of alerts that no one trusts or investigates.

Footnotes

1. NIST SP 800-53 Rev. 5

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