AC-18(2): Monitoring Unauthorized Connections

AC-18(2): monitoring unauthorized connections requirement means you must continuously watch for, detect, and respond to unapproved wireless connections to your systems and networks. Operationally, that translates to having defined “authorized vs. unauthorized,” deploying technical monitoring (WIDS/WIPS, NAC, logs), routing alerts to an on-call owner, and keeping repeatable evidence that monitoring works.

Key takeaways:

• Define what “authorized wireless” means in your environment, then treat everything else as unauthorized by default.
• Deploy monitoring that actually detects rogue APs, ad hoc hotspots, and unauthorized clients, and ensure alerts drive tickets and response actions.
• Retain assessment-ready evidence: configurations, alert samples, incident records, and periodic review output tied to a named control owner.

Wireless connectivity is an easy way for teams to get work done and an easy way for risk to enter your environment. AC-18(2) is the control enhancement that forces discipline: you cannot rely on “we don’t allow it” statements or a policy-only stance. You need operational monitoring that finds wireless connections you did not authorize, and you need to show an assessor how you know it’s working.

For most programs, the hard part is not buying a tool. It’s scoping the requirement correctly (what networks, sites, cloud-managed WLANs, remote offices, labs, and third-party spaces count), setting a clear authorization baseline, and proving continuous operation with evidence that survives staff turnover. The fastest path is to treat this as a closed-loop detection-and-response control: monitor, alert, triage, contain, eradicate, and learn.

This page gives requirement-level implementation guidance you can put into a control procedure immediately, including a practical evidence list and audit-ready talking points. Source references are limited to NIST SP 800-53 Rev. 5 materials provided. ¹

Regulatory text

Provided excerpt: “NIST SP 800-53 control AC-18.2.” ²

What the operator must do: AC-18(2) is the enhancement for wireless access that expects active monitoring for unauthorized wireless connections. In practice, an assessor will look for (1) a definition of authorized wireless, (2) technical mechanisms to detect unauthorized connections, (3) an alert-to-action workflow, and (4) retained evidence that the monitoring is operating as designed. ¹

Plain-English interpretation (what this really means)

You must be able to answer these questions with evidence:

• “How do you know someone didn’t plug in a rogue access point?”
• “How do you know a corporate device isn’t creating an unauthorized hotspot?”
• “How do you know an unauthorized wireless client isn’t connected to your network?”

Monitoring can be continuous or near-real-time depending on your architecture, but it must be systematic, repeatable, and tied to response. A spreadsheet inventory of access points helps, but it does not satisfy “monitoring” on its own.

Who it applies to (entity + operational context)

AC-18(2) is most relevant where:

• You operate federal information systems or environments aligned to NIST SP 800-53. ³
• You are a contractor handling federal data and have implemented NIST 800-53 controls in your SSP/control set. ³

Operationally, it applies anywhere wireless could exist, including:

• Corporate offices, data centers, labs, warehouses
• Remote offices and “temporary” sites
• Guest networks (still part of your environment and can become a pivot point)
• Cloud-managed WLAN environments (controller logs and security events still count)
• Third-party managed sites where your systems are present (you may need contractual right-to-monitor or compensating monitoring on your endpoints)

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

Step 1: Set your authorization baseline (the “allow list”)

Create a definition of authorized wireless that is unambiguous:

• Approved SSIDs (including naming conventions)
• Approved encryption/authentication methods (e.g., WPA2-Enterprise / WPA3-Enterprise)
• Approved AP models/MAC OUIs (if you track this)
• Approved controller(s), management plane, and configuration standards
• Approved use cases for tethering/hotspots (most orgs prohibit; if allowed, document constraints)

Deliverables:

• Wireless standard / configuration baseline
• Wireless asset inventory (APs/controllers) with owners and locations
• Exception process for non-standard wireless use

Step 2: Pick your monitoring points (where detection happens)

Most programs need more than one sensor because rogue wireless can appear in multiple ways:

A. Wireless-side monitoring (preferred where you run WLAN):

• WIDS/WIPS features on managed APs/controllers
• Dedicated RF sensors in high-risk areas (e.g., lobbies, trading floors, labs)

B. Wired-side monitoring (catches “rogue AP plugged into a switch”):

• Network Access Control (NAC) and switch port security signals
• DHCP fingerprinting and detection rules for “AP-like” behavior
• NDR/IDS detections for unusual beaconing or traffic patterns (environment-dependent)

C. Endpoint-side monitoring (critical for remote/field users):

• EDR detections for new network interfaces, bridging, ICS, hotspot creation (where supported)
• Host firewall logs and connection telemetry
• MDM controls to restrict hotspot/tethering and detect policy violations

Your goal is coverage for:

1. Rogue APs, 2) Unauthorized SSIDs, 3) Unauthorized clients, and 4) Misconfigured authorized WLAN that effectively becomes “unauthorized” (e.g., open auth).

Step 3: Define alerting and response (make it actionable)

Write a short, enforceable runbook. Minimum fields:

• Alert types (rogue AP detected, ad hoc network detected, evil twin suspected, unauthorized client)
• Severity mapping criteria (e.g., “rogue AP on corporate switch” higher than “unknown SSID nearby”)
• Triage steps (verify signal strength/location, correlate switch port, identify owner)
• Containment actions (disable switch port, quarantine device via NAC, block client, deauth via WIPS where permitted)
• Escalation path (Network Engineering, Security Ops, Facilities for physical sweep)
• Documentation requirements (ticket template fields)

Make sure alerts create durable records:

• SIEM event → incident/ticket
• Ticket includes timestamps, analyst notes, containment action, outcome, and closure approval

Step 4: Operationalize ownership and cadence (so it survives audits)

Assign:

• Control owner (accountable for AC-18(2))
• System/network owner (responsible for WLAN and switches)
• SOC owner (responsible for monitoring and response execution)

Set recurring activities:

• Review top alerts and false positives
• Validate sensor/controller health
• Reconcile wireless inventory vs observed devices
• Track exceptions and expiry

Daydream can help here by mapping AC-18(2) to a named owner, a control procedure, and a recurring evidence checklist so you can produce consistent artifacts even when tools or personnel change. ²

Step 5: Prove it works (control testing you can defend)

Run a controlled test in a non-production area (or approved window):

• Introduce a known “unauthorized” SSID (test AP) and confirm detection path
• Plug a small AP into a test switch port and confirm wired-side detections/tickets
• Validate alert routes to the right queue and triggers the runbook

Record:

• Test plan, approvals, screenshots/log extracts, and ticket outcomes

Required evidence and artifacts to retain

Keep artifacts that show design and operation:

Design evidence

• Wireless access policy + standard (authorized SSIDs, security settings)
• Network diagrams showing WLAN segments and management plane
• Tooling architecture: WIDS/WIPS, NAC, SIEM integrations
• Runbook/IR procedure for unauthorized wireless detections
• Roles and responsibilities (RACI)

Operating evidence

• SIEM/log samples showing detections (sanitized)
• Current configuration exports (controller/WIPS policies, NAC rules)
• Monthly/quarterly review notes (alert trends, tuning decisions)
• Tickets/incident records showing triage and containment
• Inventory reconciliation output (authorized AP list vs observed)
• Exception register entries (what is allowed, who approved, expiry)

Assessor tip: evidence should show a chain from detection → ticket → action → closure.

Common exam/audit questions and hangups

Auditors commonly probe:

• “Show me how you detect a rogue AP connected to an internal switch.”
• “How do you define unauthorized wireless in scope?”
• “Do you monitor all sites, including small offices and labs?”
• “What happens when an employee creates a hotspot?”
• “How do you ensure monitoring is continuous and not ‘turned off’ during network changes?”
• “Show evidence from different points in time.”

Hangups that derail reviews:

• Monitoring exists but alerts are not retained (short log retention, no SIEM)
• Alerts go to an email inbox with no ticketing or ownership
• WLAN is outsourced and you cannot obtain logs or show response actions

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Policy-only “wireless prohibited”	Doesn’t detect violations	Add technical monitoring and ticketed response
Inventory equals monitoring	Inventory is static	Correlate inventory to observed RF and wired telemetry
Only monitoring corporate SSIDs	Rogue APs don’t use corporate SSIDs	Detect unknown SSIDs, ad hoc networks, and wired rogue AP signatures
No response authority	SOC sees alerts but can’t shut ports	Pre-authorize containment steps and define escalation SLAs internally
Ignoring remote/field hotspots	Most unmanaged wireless risk lives offsite	Enforce via MDM/EDR where possible; require VPN + endpoint controls

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement. Treat the risk as operational: unauthorized wireless can bypass segmentation, expose credentials, enable unauthorized data access, and create an unmonitored path into regulated environments. Your defensible position is “we detect and respond,” backed by artifacts and repeated operational records. ³

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + baseline)

• Name the AC-18(2) control owner and SOC/network operators.
• Publish “authorized wireless” standards and an exception workflow.
• Inventory APs/controllers and confirm who administers them.
• Confirm log sources available (controller/WIPS, NAC, switches, EDR) and route key events to the SIEM.
• Draft the unauthorized wireless runbook and ticket template.

Days 31–60 (turn on detection + make alerts actionable)

• Enable WIDS/WIPS detections and tune to reduce noise.
• Implement wired-side signals for rogue AP indicators (NAC/switch alerts).
• Ensure alerts create tickets with assignment rules and escalation paths.
• Run a controlled detection test and capture evidence.
• Start recurring review meetings and record outcomes.

Days 61–90 (prove repeatability + close gaps)

• Expand coverage to smaller sites and higher-risk areas.
• Add endpoint-side controls for hotspot/tethering where feasible.
• Perform inventory vs observed reconciliation and remediate discrepancies.
• Package evidence for assessment: screenshots/config exports, sample alerts, tickets, review notes.
• In Daydream, map AC-18(2) to the owner, procedure, and recurring evidence tasks so the control stays assessable over time. ²

Frequently Asked Questions

Does AC-18(2) require a dedicated wireless intrusion prevention system (WIPS)?

The requirement is monitoring for unauthorized connections; it does not mandate a specific product. If your managed WLAN supports WIDS/WIPS features and you can prove detection and response, that often satisfies the intent.

We don’t offer Wi‑Fi in the office. Are we still on the hook?

If wireless can still appear (employee hotspots, rogue APs), auditors may expect some detection and a response plan. At minimum, document the prohibition and implement compensating monitoring on wired ports and endpoints.

How do we handle third-party managed buildings where we can’t deploy sensors?

Treat it as a dependency risk. Contract for access to relevant logs/alerts where possible, and add endpoint-based monitoring plus strict network access controls for any systems operating there.

What evidence is strongest for auditors?

Ticketed incidents (or test tickets) tied to SIEM/controller alerts, plus configuration exports showing detections are enabled. Add periodic review notes to show ongoing operation across time.

Are guest networks in scope?

If they are part of your environment, they can become a pivot to corporate resources through misconfiguration or shared infrastructure. Keep guest WLAN configurations and monitoring evidence separate but visible.

How granular does “unauthorized” need to be?

Granular enough that an operator can make a decision quickly: unauthorized SSID, unauthorized AP, unauthorized client, or unauthorized security configuration. If analysts have to interpret policy during an alert, you will get inconsistent response.

Footnotes

1. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

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

3. NIST SP 800-53 Rev. 5