AC-18: Wireless Access

To meet the ac-18: wireless access requirement, you must define and enforce documented configuration standards, connection rules, and operator guidance for every wireless technology your environment allows (for example, Wi‑Fi, Bluetooth, cellular hotspots, NFC, or Zigbee), then retain evidence that those requirements are implemented and monitored. The fastest path is to inventory wireless entry points, set “allowed vs prohibited” rules, and bind enforcement to technical controls and change management.

Key takeaways:

• Treat “wireless” as multiple access types, each with its own standard, approval path, and enforcement method. ¹
• Auditors look for alignment between written requirements, actual configurations, and repeatable evidence. ²
• Your biggest risk is “unknown wireless,” including rogue access points and unmanaged hotspotting, because you cannot prove compliant connection requirements without visibility. ²

AC-18 is an access control requirement that forces operational clarity: what wireless access is permitted, under what conditions it can connect, and how staff should implement and maintain it. The control is short, but the expectation is not. A CCO or GRC lead operationalizes AC-18 by translating it into: (1) wireless configuration baselines, (2) connection and authentication requirements, and (3) implementation guidance that engineers can follow without improvisation.

This requirement applies anywhere wireless can create an access path into systems, data, or networks in scope for your NIST SP 800-53 control set, including federal information systems and contractor systems handling federal data. ² The practical challenge is scope creep: Wi‑Fi is obvious, but Bluetooth peripherals, mobile hotspotting, conference room devices, and “smart” facilities gear can create wireless entry points too.

Your job is to make wireless predictable. That means you define what “secure wireless” means in your environment, you enforce it in your configurations and connection flows, and you keep evidence that proves you do those things consistently.

Regulatory text

Requirement (excerpt): “Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and” ¹

What an operator must do with this text

AC-18 is asking for three deliverables, for each wireless access type you allow:

1. Configuration requirements: Your baseline settings for wireless components (access points, controllers, endpoints, device profiles).
2. Connection requirements: The rules a device must satisfy to connect (approved authentication, encryption, segmentation, device posture, approvals).
3. Implementation guidance: The “how-to” that makes the first two repeatable (build steps, diagrams, exception process, and who does what).

Auditors will test that these are not aspirational documents. They will compare your standards to actual wireless configurations and operational records. ²

Plain-English interpretation (what AC-18 really means)

If wireless can connect to your environment, you must:

• Define what “approved wireless” is (by technology and use case).
• Block or control everything else (by policy and technical enforcement).
• Write down how your team implements it, so wireless security is consistent across sites, business units, and third parties.

This is the essence of the ac-18: wireless access requirement: predictable configurations, controlled connections, and repeatable operations. ¹

Who it applies to (entity and operational context)

AC-18 is commonly implemented by organizations operating:

• Federal information systems or
• Contractor systems handling federal data ²

Operationally, the control touches multiple teams:

• Network engineering (WLAN design, segmentation, controller/AP configuration)
• Endpoint engineering (device posture, certificates, MDM profiles, EDR constraints)
• Security operations (detection of rogue wireless, alerting, response)
• GRC / compliance (requirements, exceptions, evidence, assessment support)
• Facilities / physical security (IoT and building systems that introduce wireless)

If you have multiple environments (corporate IT, production, labs, OT), treat them separately. AC-18 expects “each type of wireless access” to have its own requirements, which often vary by environment.

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

Step 1: Build a wireless access inventory (what exists and what’s allowed)

Create a simple register that lists:

• Wireless access types in use or possible (Wi‑Fi, Bluetooth, cellular hotspotting, NFC, Zigbee/Thread, etc.)
• Where used (site, VLAN/segment, SSID, system boundary)
• Owner and operator
• Connection purpose (employee access, guest access, IoT, point-to-point bridges)
• Current enforcement controls (controller policy, NAC, MDM, firewall segmentation)

This register becomes the backbone for “each type of wireless access.” ¹

Step 2: Define configuration requirements per wireless type

For each allowed wireless type, write configuration requirements in a standard that engineers can implement. Keep it short, but testable. Examples of configuration requirement categories:

• Radio settings and approved bands
• SSID naming/usage rules (if Wi‑Fi)
• Approved encryption/authentication modes
• Logging settings (what must be recorded and where it’s sent)
• Management plane controls (who can administer controllers/APs and how)

Avoid brand-specific language in the compliance standard. Put vendor-specific commands in an engineering runbook linked to the standard.

Step 3: Define connection requirements (the “must-pass gates”)

Connection requirements should be written as “a device may connect only if…” statements, such as:

• The connecting identity is known and authenticated
• Encryption is enforced for the connection
• Access is segmented to the minimum necessary network routes
• Devices meet your endpoint management expectations for the relevant use case

Even if your enforcement mechanism differs by environment, the rule must be consistent and explainable. This is where exam teams look for gaps between policy and reality. ²

Step 4: Write implementation guidance that matches how work gets done

Implementation guidance should answer:

• Who requests wireless access, and how
• Who approves, and based on what criteria
• How changes are implemented (change ticketing, peer review, maintenance windows if you use them)
• How exceptions are granted and tracked
• How you verify enforcement (tests, scans, or config review)

The goal is “no heroics.” A new engineer should be able to follow the guidance and produce a compliant result.

Step 5: Bind AC-18 to operational control owners and recurring evidence

Make AC-18 assessable by mapping it to:

• A control owner (accountable)
• Implementers (responsible)
• A review cadence you can sustain
• Evidence artifacts you can export repeatedly

A practical pattern is to build an “AC-18 evidence pack” checklist (see next section) and assign it to a named owner in your GRC system. Daydream is commonly used here to keep the owner, procedure, and recurring evidence tied together so assessments do not turn into screenshot drills. ¹

Step 6: Monitor for drift and “unknown wireless”

AC-18 fails quietly if wireless configurations drift or if rogue wireless appears (unapproved access points, ad-hoc tethering, shadow IT devices). Define:

• What you monitor (controller configs, SSID inventory, detection alerts)
• Who triages alerts
• What remediation looks like (disable port, remove device, user coaching, incident handling)

You are defending an access path. Treat it like one.

Required evidence and artifacts to retain

Keep evidence that proves (a) requirements exist, (b) they are implemented, and (c) they are operating. A strong AC-18 evidence set includes:

Governance artifacts

• Wireless Access Standard covering configuration + connection requirements for each wireless type ¹
• Implementation runbook(s) or SOPs referenced by the standard
• Exceptions register for wireless deviations (with approval and expiration)

Technical artifacts

• Exported WLAN controller/AP configuration snapshots or policy exports
• Network diagrams showing segmentation for wireless networks (employee/guest/IoT)
• Authentication configuration evidence (for example, certificate-based profiles if used)
• Logging evidence: where wireless logs go and sample events

Operational artifacts

• Change records for wireless config changes
• Access/approval records for new SSIDs or wireless deployments
• Monitoring outputs for rogue detection or periodic wireless discovery
• Issue tickets showing remediation of unauthorized wireless

Your evidence should map back to “each type of wireless access,” not only corporate Wi‑Fi.

Common exam/audit questions and hangups

Expect assessors to ask:

• “List every wireless technology in scope. How do you know you didn’t miss one?”
• “Show me the configuration standard, then show me the actual controller/AP configuration that matches it.”
• “How do you prevent employee hotspotting from bridging managed endpoints to unmanaged networks?”
• “How do guests connect, and what stops guest traffic from reaching internal systems?”
• “Show me your exception process and an example exception.”

Common hangup: a beautiful policy with no proof it’s implemented. AC-18 is short; evidence depth makes or breaks you. ²

Frequent implementation mistakes (and how to avoid them)

1. Writing one Wi‑Fi policy and calling it done.
   Fix: maintain the “wireless types register” and require a standard per type. ¹

2. No separation between employee, guest, and IoT wireless.
   Fix: document connection requirements that include segmentation expectations, then retain diagrams and config exports that prove separation.

3. Relying on “tribal knowledge” for configuration.
   Fix: convert the build steps into implementation guidance and tie it to change management artifacts.

4. No exception discipline.
   Fix: require written risk acceptance, documented compensating controls, and an expiration date in your exception record.

5. Evidence that cannot be reproduced.
   Fix: define recurring exports (controller policy export, SSID list, monitoring report) so you can regenerate evidence on demand.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk-wise, wireless is a high-utility path for unauthorized access because it can bypass physical controls and extend networks beyond facility boundaries. AC-18 reduces that risk by forcing you to define approved wireless paths and prove they are controlled through configuration and connection requirements. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and rules)

• Appoint the AC-18 control owner and identify engineering operators. ¹
• Build the wireless types register and validate it with network, endpoint, facilities, and security operations.
• Publish a first version Wireless Access Standard: allowed wireless types, prohibited types, and minimum connection requirements per allowed type. ¹
• Identify quick wins: disable unused SSIDs, remove stale PSKs if present, restrict admin access paths.

By 60 days (implement and evidence)

• Convert the standard into implementation guidance (SOP/runbook) that matches how changes are requested and deployed. ¹
• Align controller/AP configs to the standard; open tracked remediation items for gaps.
• Stand up an evidence pack: configuration exports, diagrams, logging samples, and change records stored in an assessment-ready location.
• Formalize exceptions: intake form, approvers, and storage.

By 90 days (operationalize and monitor)

• Implement a drift-check process: periodic config review and SSID inventory reconciliation.
• Operationalize unauthorized wireless response: detection source, triage owner, and ticket workflow.
• Run an internal “tabletop audit”: pick one wireless type and walk from requirement → config → logs → change record → exception example.
• In Daydream, map AC-18 to the owner, the implementation procedure, and the recurring evidence artifacts so future audits are repeatable. ¹

Frequently Asked Questions

Does AC-18 apply if we “don’t have Wi‑Fi” in production?

Yes if any wireless access type exists or could be introduced in scope, including hotspots, Bluetooth peripherals, or IoT wireless. AC-18 is written as “each type of wireless access,” not only Wi‑Fi. ¹

What counts as “implementation guidance” versus policy?

Policy states the rules (configuration and connection requirements). Implementation guidance tells engineers and operations staff exactly how to implement, approve, test, monitor, and document those rules. ¹

Do we need separate standards for guest Wi‑Fi and employee Wi‑Fi?

If they have different connection requirements, treat them as distinct wireless access types or distinct use cases with separate requirement sections and separate evidence. Assessors will test that requirements match actual segmentation and access paths. ²

How do we handle third-party-managed wireless (for example, a managed office provider)?

Put the third party under contract requirements that mirror your configuration and connection requirements, then collect evidence (config attestations, change records, and monitoring outputs) as part of third-party due diligence and ongoing oversight. ²

What evidence is strongest for AC-18 in an assessment?

A written wireless standard per wireless type plus exported configurations from the wireless platform that show the settings in force, and change records proving controlled updates. Add logs or monitoring outputs that demonstrate operational oversight. ²

Can we meet AC-18 with compensating controls if wireless is required but legacy?

Yes, but document the exception, the compensating controls, and the plan to remediate. Keep the exception time-bound and collect evidence that the compensating controls operate. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5