AC-18: Wireless Access

What this control requires

AC-18 requires you to authorize and configure every wireless technology before any device connects. That distinction matters because wireless introduces an access path that exists outside your physical perimeter, and treating it as an extension of wired networking is how unauthorized connections persist undetected.

In practice, you need two deliverables. First, documented configuration and connection requirements that cover each wireless technology in your environment, from 802.11x enterprise Wi-Fi to Bluetooth peripherals and microwave links. Second, a formal authorization process that approves each wireless access type before it goes live.

In practice, a designated authority reviews the risk profile, authentication method, and encryption standard for every wireless technology and signs off before users connect. Without that pre-connection authorization, organizations end up with rogue access points, misconfigured protocols, and wireless connections that bypass every network segmentation control they’ve invested in.

Why it matters

Wireless access failures rarely surface as dramatic incidents. They surface as audit findings, failed authorization evidence, and uncontrolled access paths that erode the credibility of your entire access control program.

The result is audit exposure across every baseline. Because this control sits in LOW, MODERATE, and HIGH baselines, assessors expect wireless configuration standards and authorization records regardless of your system categorization. Missing or incomplete evidence here cascades into findings against related controls like AC-17 (Remote Access) and IA-02 (Identification and Authentication), compounding a single gap into a systemic deficiency.

Specifically, this exposure extends to third-party assessors and customers reviewing your security posture. They will flag undocumented wireless access as a control environment weakness, undermining trust in your broader access control architecture.

Where this breaks down operationally, wireless technologies introduce threat vectors that attackers actively exploit:

• Rogue access points deployed inside your network perimeter, bypassing firewall and segmentation controls entirely
• Evil twin attacks that impersonate legitimate enterprise service set identifiers (SSIDs) to harvest credentials through fake captive portals
• Bluetooth exploitation targeting unmanaged peripherals and IoT devices that lack mutual authentication
• Weak or absent wireless authentication protocols that allow unauthorized devices to associate with production networks
• Unmonitored wireless spectrum where unauthorized connections persist because no one is scanning for them

How to implement

Wireless access controls fail most often not because organizations lack a policy, but because the policy doesn’t map to specific technologies and no one enforces the authorization step before new wireless connections go live. This is one of the most common gaps in the NIST SP 800-53 access control family.

For your organization

Start by inventorying every wireless technology in your environment. This includes enterprise Wi-Fi (802.11x), Bluetooth devices, wireless keyboards, packet radio links, and any microwave connections. Most organizations undercount by ignoring Bluetooth peripherals and IoT sensors.

In practice, each technology type needs its own documented configuration requirements. For 802.11x networks, this means specifying WPA3-Enterprise or WPA2-Enterprise with 802.1X authentication, disabling Wi-Fi Protected Setup (WPS), and mandating mutual authentication between clients and access points. For Bluetooth, specify pairing restrictions, disable discoverable mode on managed devices, and restrict Bluetooth profiles to business-justified uses.

In practice, this means defining connection requirements that specify who can connect, from which device types, and under what conditions. Wireless connections should integrate with your identity provider and enforce the same authentication policies as wired access.

Where most organizations fall short is authorization. Build a formal wireless access authorization process where a designated authority reviews and approves each wireless technology before deployment. Maintain authorization records that document the technology type, authentication method, encryption standard, approving authority, and approval date.

The result is that monitoring becomes your final verification layer. Deploy wireless intrusion detection or prevention to identify rogue access points and unauthorized connections. Scan your wireless spectrum regularly to catch devices that bypass your authorization process.

Common mistakes that weaken this control:

• Treating guest Wi-Fi as out of scope for AC-18 (it isn’t; every wireless access type requires configuration standards)
• Authorizing “Wi-Fi” generically instead of documenting requirements per technology type
• Failing to update configuration requirements when new wireless protocols or devices enter the environment
• Storing authorization records in email threads instead of a retrievable evidence repository

For your vendors

When evaluating vendor compliance with AC-18, your goal is to verify that the vendor treats wireless access as a controlled, documented, and authorized access path rather than an unmanaged convenience.

Ask these questions in your vendor assessment questionnaire:

• Do you maintain documented configuration requirements for each type of wireless access in your environment?
• What wireless authentication protocols do you enforce, and do they provide mutual authentication?
• Is each type of wireless access formally authorized before deployment, and who holds authorization authority?
• How do you detect and respond to rogue access points or unauthorized wireless connections?
• Do your wireless access controls apply to Bluetooth, IoT, and other non-Wi-Fi wireless technologies?

Request these evidence artifacts:

• Wireless access policy with technology-specific configuration standards
• Sample wireless access authorization records showing approver, date, and technology details
• Wireless network architecture diagram identifying access points, segmentation boundaries, and authentication mechanisms aligned with networks security best practices
• Most recent wireless vulnerability scan or penetration test results
• Wireless intrusion detection system (WIDS) logs or scan reports

Watch for these red flags during assessment:

• The vendor provides a generic “network security policy” with no wireless-specific sections
• Authorization records reference “wireless access” without distinguishing between technology types
• No evidence of wireless spectrum monitoring or rogue access point detection
• The vendor excludes Bluetooth and IoT wireless technologies from the control scope
• The vendor cannot demonstrate mutual authentication on their wireless networks

Specifically, verification should go beyond self-attestation. Request screenshots of wireless controller configurations showing authentication and encryption settings. Ask for WIDS alert samples that demonstrate active monitoring.

In practice, if the vendor operates in a shared facility, you should confirm their controls address CIS Controls for wireless segmentation and isolation from co-tenant networks.

Evidence examples

Cross-framework mapping

Related controls

• AC-02 — Account Management: wireless access authorization depends on properly managed accounts that map to approved users and device identities
• AC-03 — Access Enforcement: wireless connections must pass through the same access enforcement mechanisms applied to wired network paths
• AC-17 — Remote Access: wireless access from outside organizational facilities overlaps with remote access controls and may require VPN or encrypted tunnel enforcement
• AC-19 — Access Control for Mobile Devices: mobile devices frequently connect over wireless, making device-level controls a prerequisite for effective wireless access management
• CA-09 — Internal System Connections: wireless access points represent internal system connections that require documented agreements and security interface definitions
• CM-07 — Least Functionality: disabling unnecessary wireless protocols and services reduces the wireless attack surface and supports least functionality principles
• IA-02 — Identification and Authentication (Organizational Users): wireless networks must enforce organizational user authentication through 802.1X or equivalent protocols
• IA-03 — Device Identification and Authentication: wireless devices require identification and authentication before gaining network access, particularly in environments using certificate-based authentication
• IA-08 — Identification and Authentication (Non-organizational Users): guest and contractor wireless access requires non-organizational user authentication controls separate from enterprise wireless
• PL-04 — Rules of Behavior: acceptable use policies must address wireless access restrictions, prohibited activities on wireless networks, and consequences for unauthorized wireless connections

Frequently asked questions

What is NIST SP 800-53 AC-18

AC-18 is the NIST SP 800-53 control that requires organizations to establish configuration requirements, connection requirements, and implementation guidance for each wireless technology type and to authorize each type before allowing connections. It applies across LOW, MODERATE, and HIGH baselines, making it a universal requirement for federal systems and any organization adopting the NIST framework. The control covers all wireless technologies, including 802.11x, Bluetooth, packet radio, and microwave links.

What happens if AC-18 is not implemented

Without AC-18, wireless connections operate without documented configuration standards or formal authorization, creating uncontrolled access paths into your network. Assessors will flag the absence of wireless access authorization records and technology-specific configuration requirements as a control deficiency. That finding cascades across the access control family because wireless gaps undermine related controls for remote access, device authentication, and network segmentation.

How do you audit AC-18

Auditing AC-18 starts with verifying that documented configuration requirements exist for each type of wireless access in the environment, including Wi-Fi, Bluetooth, and any packet radio or microwave technologies. Examine wireless access authorization records to confirm that each technology was formally approved before deployment, with evidence of the approving authority and the specific connection parameters reviewed. Review wireless intrusion detection logs and system audit records to validate that the organization actively monitors for unauthorized wireless connections and rogue access points.

What is the difference between AC-17 and AC-18

AC-17 governs remote access, covering connections from external locations to organizational systems through VPNs, remote desktop protocols, and similar technologies regardless of the transport medium. AC-18 governs wireless access specifically, addressing the configuration, connection, and authorization requirements for wireless technologies like 802.11x and Bluetooth. A remote worker connecting over a home Wi-Fi network triggers both controls. AC-18 applies to the wireless access type authorization, while AC-17 governs the remote connection itself.