Wireless Access

To meet the wireless access requirement (NIST SP 800-53 Rev 5 AC-18), you must define approved wireless types, document secure configuration and connection rules for each, publish implementation guidance, and formally authorize each wireless use case before it’s allowed to connect to your system (NIST Special Publication 800-53 Revision 5). Treat wireless as “deny by default” unless it is explicitly approved, configured, and evidenced.

Key takeaways:

• Build a wireless access inventory and approval register by wireless type (Wi‑Fi, Bluetooth, cellular/modems, NFC, etc.).
• Standardize “configuration + connection + guidance” for each type, then enforce it via technical controls and change management.
• Keep audit-ready evidence: approved designs, configs, authorization decisions, and continuous monitoring outputs.

Wireless access is a recurring audit pain point because it’s easy for teams to “accidentally allow” it: a forgotten office SSID, a rogue access point plugged into a switch, a laptop hotspot used for convenience, or a cellular modem quietly bypassing corporate controls. AC-18 forces discipline: wireless is permitted only when you have defined how it must be configured, how it is allowed to connect, and how staff must implement it. Then you must explicitly authorize each type of wireless access before it touches the system (NIST Special Publication 800-53 Revision 5).

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize this is to treat wireless like a mini-program with four concrete outputs: (1) a wireless access standard, (2) per-wireless-type build sheets (secure baselines + connection requirements), (3) an authorization workflow tied to change management, and (4) evidence that enforcement is real (technical settings, monitoring, and exceptions). Done well, AC-18 becomes straightforward: you can point to what wireless is allowed, why, under what conditions, and where those conditions are enforced.

Regulatory text

Control requirement (excerpt): “Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and authorize each type of wireless access to the system prior to allowing such connections.” (NIST Special Publication 800-53 Revision 5)

What this means in plain English

You must do two things:

1. Define the rules for wireless by wireless type. For each type (for example: Wi‑Fi, Bluetooth, cellular modems, NFC), you need documented requirements that cover:

• Configuration requirements: how the wireless capability is set up securely (settings, encryption, device hardening).
• Connection requirements: what it can connect to and under what conditions (approved networks, segmentation, authentication, VPN).
• Implementation guidance: instructions for engineering and operations that make the requirements repeatable (how to deploy, who approves, how to monitor, what to do when it breaks).

2. Authorize wireless before use. Wireless access is not “allowed until someone complains.” Each wireless type must be explicitly approved for the system before connections are permitted (NIST Special Publication 800-53 Revision 5).

This is a governance requirement with teeth: documentation alone fails if the environment still allows ad hoc wireless connections.

Who it applies to

Entity scope

• Cloud Service Providers (CSPs) operating systems aligned to FedRAMP Moderate expectations.
• Federal agencies operating or authorizing systems where AC-18 is in scope. (NIST Special Publication 800-53 Revision 5)

Operational scope (where AC-18 shows up)

AC-18 applies anywhere your “system” could be accessed via wireless, including:

• Corporate facilities and office networks that support system administration or developer access.
• Data centers, cages, or labs with any wireless-capable equipment.
• End-user computing used to access production consoles (laptops, tablets, phones).
• Embedded wireless capabilities on servers, workstations, or peripherals (Bluetooth, Wi‑Fi radios).
• Third-party-managed spaces where your system is accessed (contractor offices, co-lo sites) if it affects the authorized boundary and connections.

If you cannot clearly explain where wireless is allowed, auditors will assume wireless is uncontrolled.

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

Step 1: Define “wireless types” and build your wireless inventory

Create a list of wireless access types relevant to your environment. Common categories:

• Wi‑Fi (802.11) for corporate/guest/admin access
• Bluetooth (keyboards, headsets, file transfer)
• Cellular data / tethering / mobile hotspots
• RFID/NFC
• Zigbee/IoT protocols (if you have facilities/IoT)
• Point-to-point wireless bridges (rare, but high risk)

Then inventory where wireless exists or could exist:

• Physical access points, controllers, SSIDs, and their mapped VLANs/subnets
• Wireless-capable endpoints (laptops, phones, tablets)
• Any “hidden wireless” (printers, conference room devices, dev kits)
• Third-party equipment in your spaces

Output artifact: Wireless Access Inventory (by type, owner, location, purpose, boundary impact).

Step 2: Establish configuration requirements per wireless type (the “secure baseline”)

For each wireless type, write a short baseline that an engineer can implement without interpretation. Keep it tight and testable. Examples of configuration requirement statements:

• Wi‑Fi must use approved encryption/authentication methods, logging, and management protections.
• Bluetooth must be disabled by default except for approved profiles, with discoverability restricted.
• Cellular modems must be prohibited on system-admin devices unless explicitly approved.

Avoid vague phrases like “strong encryption.” Replace with enforceable statements your team can map to settings.

Output artifact: Wireless Configuration Standards (one section per wireless type).

Step 3: Define connection requirements (where wireless may connect and how)

Connection requirements should answer:

• What networks can this wireless connect to (corp, guest, segmented admin)?
• What identity is required (device identity, user identity, MFA where applicable)?
• Is a VPN required for access to sensitive/admin paths?
• What segmentation and firewall rules apply?
• Are there time/location restrictions?

This is where you prevent “SSID equals internal LAN” designs. Most findings happen when wireless is bridged into trusted networks without compensating controls.

Output artifact: Wireless Connection Requirements Matrix (wireless type × allowed destinations × required controls).

Step 4: Publish implementation guidance (make it repeatable)

Implementation guidance is the “how-to” that prevents tribal knowledge. Include:

• Standard build steps (controller templates, endpoint profiles, MDM policies)
• Required tickets/approvals to enable a new SSID or allow a device class
• Minimum logging/monitoring requirements and where logs go
• Incident steps for rogue AP detection or suspicious wireless activity
• Exception process (who can grant, how documented, expiration)

Output artifact: Wireless Implementation Runbook (operations-ready).

Step 5: Create an authorization workflow that gates wireless enablement

AC-18 requires authorization before allowing wireless connections (NIST Special Publication 800-53 Revision 5). Operationalize authorization like this:

• Create a Wireless Authorization Register with entries per wireless type/use case.
• Tie authorization to change management: no production wireless change without a change record that references the authorized standard.
• Define approvers: typically System Owner (or delegated), Information Security, Network Engineering, and Compliance/GRC for evidence integrity.
• Define what “authorized” means: approved design + implemented controls + monitoring enabled + evidence attached.

Output artifact: Wireless Authorization Register + approval records (tickets, CAB minutes, e-sign approvals).

Step 6: Enforce technically (policy without enforcement fails audits)

Pick enforcement mechanisms that match your environment:

• MDM/endpoint management to disable radios or restrict Bluetooth profiles on managed devices
• Network access controls and segmentation to limit what wireless can reach
• Wireless controller configurations that enforce security settings centrally
• Continuous monitoring to detect rogue access points and unauthorized SSIDs

If you rely on “employees will comply,” expect audit friction. Auditors look for proof the configuration is real.

Output artifact: Screenshots/exports of controller settings, MDM profiles, network diagrams, and monitoring alerts.

Step 7: Monitor and review changes continuously

Wireless changes frequently. Put lightweight governance around:

• New office buildouts and network refreshes
• New device types (headsets, conferencing gear)
• Third-party site onboarding
• Incident learnings

Output artifact: Periodic review notes, exception log, and updated inventory.

Required evidence and artifacts to retain (audit-ready checklist)

Maintain a single evidence folder with these items:

• Wireless Access Inventory (by type, owner, location, boundary relevance)
• Wireless Configuration Standards ¹
• Wireless Connection Requirements Matrix
• Wireless Implementation Runbook
• Wireless Authorization Register, with approval records showing authorization occurred before enablement
• Change tickets for wireless-related changes (SSIDs, controller updates, segmentation changes)
• Network diagrams showing wireless segmentation and paths to system components
• MDM/endpoint configuration profiles showing wireless/Bluetooth restrictions (where applicable)
• Monitoring evidence: rogue AP detections, wireless logs forwarding, alerting configuration
• Exceptions: documented risk acceptance, compensating controls, expiration, and closure evidence

Common exam/audit questions and hangups

Auditors and 3PAOs commonly press on:

• “List every wireless type you allow and where it’s documented.”
• “Show me how wireless was authorized before it was enabled.” (Expect to produce tickets/approvals.)
• “How do you prevent an employee from using a hotspot to bypass controls?”
• “Where is wireless segmented, and how do you prove it?”
• “How do you detect rogue access points?”
• “How do third parties connect wirelessly, if at all, and what prevents lateral movement?”

Hangup pattern: teams can describe their Wi‑Fi, but cannot address Bluetooth/cellular tethering or embedded wireless on endpoints.

Frequent implementation mistakes (and how to avoid them)

1. Only documenting Wi‑Fi. Fix: treat “wireless” as a set of types; explicitly prohibit what you don’t support, and document the prohibition.
2. Authorization exists only as a policy statement. Fix: maintain an authorization register with concrete approvals and link it to change management.
3. Guest Wi‑Fi can reach trusted services. Fix: document and enforce segmentation and egress rules; keep guest isolated.
4. No ownership. Fix: assign an accountable owner per wireless type (network, endpoint, facilities/IoT).
5. Exceptions never expire. Fix: require expirations and closure evidence for any wireless exception.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so focus on audit and operational risk: wireless is a common path around perimeter controls and a common source of “unknown connections.” AC-18 reduces that exposure by requiring pre-authorization and consistent, testable standards (NIST Special Publication 800-53 Revision 5).

Practical 30/60/90-day execution plan

First 30 days (stabilize and document what exists)

• Name owners for each wireless type and a single accountable program owner.
• Build the Wireless Access Inventory (focus on Wi‑Fi, Bluetooth, cellular/hotspots first).
• Decide “allowed vs prohibited” per type and document prohibitions explicitly.
• Draft the Wireless Authorization Register and define approvers.
• Identify quick technical wins (disable unused radios on standard builds; lock down Bluetooth sharing).

By 60 days (standardize and gate changes)

• Publish configuration and connection requirements per wireless type.
• Publish the implementation runbook used by engineering and IT.
• Update change management so wireless changes require referencing the authorization record.
• Implement controller/MDM baselines that match your written standards.
• Stand up basic monitoring for rogue APs and wireless events and route to your logging pipeline.

By 90 days (prove it works and make it auditable)

• Run an internal control test: sample wireless changes and verify “authorized before enabled.”
• Validate segmentation with a simple connectivity test plan and retain evidence.
• Review exceptions; close stale ones and add expirations where missing.
• Prepare an “audit pack” with all artifacts, plus a one-page wireless architecture diagram.
• If you need a system to keep approvals, evidence, and exception renewals from drifting, Daydream can centralize the control narrative and evidence mapping so AC-18 stays current without spreadsheet churn.

Frequently Asked Questions

Do we have to allow wireless access to meet AC-18?

No. You can prohibit some or all wireless types. AC-18 still expects documented requirements and authorization decisions; “prohibited” should be explicit, enforced, and evidenced (NIST Special Publication 800-53 Revision 5).

What counts as a “type of wireless access”?

Treat each distinct wireless protocol or connection path as a type (for example Wi‑Fi, Bluetooth, cellular tethering). If it creates a new way to reach your system or administer it, document it as its own type with its own requirements.

How do we show “authorize prior to allowing” in an audit?

Produce an approval record dated before the configuration went live, plus the change ticket implementing it. Auditors look for a clean chain: requirement → authorization decision → change record → enforced configuration (NIST Special Publication 800-53 Revision 5).

We’re a SaaS provider. Does office Wi‑Fi matter to the system boundary?

It can. If engineers or admins reach production or management interfaces from corporate networks, your wireless controls become relevant. Document the path, restrict it, and keep evidence that wireless cannot bypass your admin access controls.

What about third parties on-site (contractors, assessors) who need connectivity?

Treat it as a wireless use case. Put them on isolated networks with documented connection requirements, and record the authorization decision and any time-bounded exception approvals.

Is a written policy enough if we don’t have wireless controllers everywhere?

Policy alone rarely satisfies AC-18. You need evidence of enforcement appropriate to your environment, such as endpoint restrictions, segmentation, and monitoring outputs that show you can detect and respond to unauthorized wireless connections (NIST Special Publication 800-53 Revision 5).

Footnotes

1. NIST Special Publication 800-53 Revision 5