AC-18(1): Authentication and Encryption

AC-18(1) requires you to protect every wireless connection to your system with strong authentication for authorized users/devices and encryption for data in transit over the air. To operationalize it fast, inventory all wireless paths, enforce WPA3-Enterprise (or documented equivalent) with certificate-based auth, disable insecure protocols, and retain configuration evidence and test results. ¹

Key takeaways:

• Wireless access must be protected with both authentication and encryption, not one or the other. ¹
• Scope includes corporate Wi‑Fi, guest segregation, warehouses, OT/IoT radios, and any third-party-managed wireless that touches your system boundary.
• Auditors look for provable enforcement: configs, RADIUS/IdP settings, cipher suites, exceptions, and periodic validation evidence.

The ac-18(1): authentication and encryption requirement is one of those controls that is simple to state and easy to fail in practice. “Wireless” is rarely just office Wi‑Fi. It includes guest networks that accidentally bridge, access points installed by facilities teams, warehouse handheld networks, conference room devices, cellular hotspots used for “temporary” access, and third-party-managed WLANs inside colocation sites. AC-18(1) forces you to treat those paths as first-class access channels that need the same rigor you apply to wired ports and VPN.

Operationally, you need two things working together: (1) an authentication mechanism that proves the user and/or device is allowed to use wireless to reach the system, and (2) encryption that protects the wireless traffic from interception and tampering. The compliance outcome is not “we have Wi‑Fi.” The outcome is “every wireless path into the system is access-controlled and encrypted, and we can show it with evidence.”

This page gives you requirement-level implementation guidance you can hand to the network/security team, then turn into assessable artifacts for your SSP, policies, and audit binder. ²

Regulatory text

NIST excerpt (AC-18(1)): “Protect wireless access to the system using authentication of {{ insert: param, ac-18.01_odp }} and encryption.” ¹

Operator interpretation (what you must do):

• “Wireless access to the system” means any radio-based network path (Wi‑Fi, point-to-point wireless bridges, and other wireless LAN technologies) that provides connectivity into the system’s boundary or to system components.
• “Using authentication” means users and/or devices must prove identity/authorization before they can send traffic into the system over wireless.
• “And encryption” means wireless traffic must be encrypted with modern protocols and strong cryptography to prevent eavesdropping or session hijacking over the air.

Your job as CCO/GRC lead: make sure engineering’s implementation is consistent across sites, exceptions are controlled, and evidence is repeatable.

Plain-English interpretation of the requirement

If a device can connect over the air to anything that is “in” your system (or routes to it), that connection must:

1. require a verified identity (user and/or device), and
2. encrypt the wireless traffic.

Open networks, shared passwords with no device identity, legacy ciphers, and “temporary” hotspots are the usual failure modes.

Who it applies to (entity and operational context)

Primary applicability

• Federal information systems and contractor systems handling federal data that adopt NIST SP 800-53 as a control baseline. ²

Operational scope you should assume unless you have a documented system boundary that excludes it

• Corporate and campus Wi‑Fi (employee SSIDs).
• Guest Wi‑Fi if it can reach any system component, management plane, or shared services (DNS, AD, MDM, ticketing, monitoring).
• Warehouse, retail, clinic, and field-office WLANs.
• OT/IoT wireless segments (scanners, cameras, building management sensors) if they transit or manage system components.
• Wireless infrastructure managed by a third party (MSP-managed WLAN, colocation “smart hands” networks) when it connects to your environment.

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

Use this sequence to drive implementation and evidence collection.

1) Define and publish wireless scope (boundary-first)

• Build a wireless access inventory: SSIDs, VLANs, access points, controllers, wireless bridges, and authentication backends (RADIUS/IdP). Include owners and locations.
• Mark which networks can reach the system boundary (directly or through routing).
• Document allowed wireless technologies and explicitly disallow ad-hoc hotspots for system access, except via an approved process.

Output: “Wireless Access Register” tied to your system boundary diagrams.

2) Pick an approved authentication pattern and standardize it

Common acceptable patterns (choose and document one or more):

• Enterprise Wi‑Fi with per-user authentication (e.g., 802.1X via RADIUS backed by IdP).
• Device-based authentication (certificate-based EAP-TLS) for managed endpoints and headless devices.
• Separate flows for headless/IoT with device identities, not shared passwords.

What to avoid (or strictly exception-control):

• Shared PSKs for any SSID that routes to the system.
• “MAC allowlists” as the primary control (too easy to spoof).
• Vendor default credentials on APs/controllers.

Decision point for GRC: If engineering proposes PSK “because it’s easier,” require a compensating control package plus a dated migration plan.

3) Enforce encryption that matches the authentication strength

• Configure the WLAN for strong encryption (for Wi‑Fi, this typically maps to WPA2-Enterprise or WPA3-Enterprise; document what you use and why).
• Disable legacy protocols and weak cipher suites on controllers/APs.
• Ensure management-plane access to wireless infrastructure is also protected (admin interfaces should not be on an open or guest segment).

Evidence goal: You can show the exact security mode, encryption protocol, and key management approach.

4) Segment wireless so “guest” cannot become “system access”

• Put guest SSIDs on isolated VLANs with internet-only egress.
• Block lateral movement from guest/IoT WLANs to corporate/system VLANs.
• Limit routing from WLANs to only necessary services.

Common assessor angle: “Show me the firewall rules between guest Wi‑Fi and system subnets.”

5) Implement monitoring and configuration control

• Centralize WLAN configuration management (controller-based or managed platform).
• Log authentication events (RADIUS/IdP logs) and keep them available for incident response and audits.
• Create alerts for:
  • New SSIDs
  • Security mode changes (e.g., WPA3 → WPA2/OPEN)
  • Rogue AP detection where supported

6) Build an exception process for unavoidable legacy

If you have legacy scanners, medical devices, or OT endpoints:

• Require a formal exception ticket with business owner, compensating controls (segmentation, NAC, device isolation), and an end date.
• Track exceptions in a register that the auditor can sample.

7) Make it assessable: map ownership, procedure, and recurring evidence

This control fails most often because teams cannot produce consistent proof across sites and quarters. Assign:

• Control owner (network/security engineering).
• Accountable executive (CISO or Head of IT).
• Recurring evidence cadence (aligned to your audit cycle). A tool like Daydream is useful here because it turns AC-18(1) into an owned control with a repeatable evidence checklist and reminders, so evidence collection doesn’t restart from scratch each audit.

Required evidence and artifacts to retain

Keep artifacts that show design and operation.

Design / configuration

• Wireless network diagrams (SSIDs → VLANs → firewall zones → system boundary).
• Controller/AP configuration exports showing:
  • Authentication mode (e.g., 802.1X/EAP method)
  • Encryption mode and allowed ciphers
• RADIUS/IdP configuration snippets (realm, policies, certificate requirements).
• Standards/baselines for wireless security configuration.

Operational

• Change records for WLAN security changes (tickets/approvals).
• Sample authentication logs (RADIUS accept/reject) showing enforcement.
• Results of periodic validation (internal scan or configuration review).
• Exception register for any non-standard wireless configurations.

Policy / governance

• Wireless access policy and standard.
• Access control procedure for provisioning/deprovisioning wireless access.
• Third-party management attestations if a third party operates your WLAN.

Common exam/audit questions and hangups

Auditors and assessors tend to ask:

• “List every SSID that can reach the system. Which one is guest?”
• “Show the exact authentication method and encryption settings on the controller.”
• “How do you prevent a shared password from spreading to unauthorized users?”
• “How do you handle IoT/headless devices that cannot use interactive auth?”
• “Show evidence this is consistently applied across all sites, not just HQ.”
• “What happens when the wireless controller config changes?”

Hangups that cause findings:

• Inconsistent settings across AP groups/sites.
• “Temporary” SSIDs left behind after events.
• Guest Wi‑Fi reaching internal DNS or management networks.
• Missing evidence because configs are not exported or reviewed on a schedule.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-18(1)	Fix
Relying on a shared PSK for corporate/system SSID	Authentication is weak and non-attributable	Move to 802.1X with per-user or per-device identity; document exceptions
Treating “guest Wi‑Fi” as out of scope by name	Routing, DNS, or misconfig can create access	Prove isolation with diagrams + firewall rules + tests
Leaving WPA modes permissive for compatibility	Clients may negotiate weaker encryption	Disable legacy/transition modes where possible; tightly control where not
No recurring evidence	You cannot show ongoing compliance	Set scheduled config exports and reviews; store artifacts centrally
Ignoring third-party-managed WLAN	Access path still exists	Contractually require configs/evidence; test segmentation at your boundary

Enforcement context and risk implications

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

Risk is still straightforward: weak wireless authentication or missing encryption enables credential theft, session interception, and unauthorized network access from a parking lot or adjacent office. For federal and federal-adjacent environments, that can translate into assessment findings, delayed ATO, customer trust issues, and breach exposure.

A practical 30/60/90-day execution plan

Use phases instead of date promises; execution speed depends on site count, legacy devices, and WLAN architecture.

Immediate (stabilize and stop new risk)

• Assign a single accountable owner for wireless security settings.
• Pull current controller/AP configs and identify any open or PSK networks that route to system subnets.
• Disable any unknown SSIDs and lock down who can create new SSIDs.
• Start an exceptions register for anything you cannot remediate quickly.

Near-term (standardize and enforce)

• Implement your standard enterprise auth pattern (per-user and/or per-device identity).
• Enforce strong encryption modes across all in-scope SSIDs.
• Segment guest and IoT networks with explicit deny rules into system zones.
• Set up centralized log collection for wireless auth events.

Ongoing (prove and maintain)

• Schedule recurring evidence: config exports, log samples, and a review of SSID inventory.
• Test isolation controls (guest → system) and document results.
• Review exceptions monthly; require closure plans and validate compensating controls.
• Track changes through tickets and approvals to prevent silent drift.

Frequently Asked Questions

Does AC-18(1) apply if we only use Wi‑Fi for internet access?

It applies if that wireless network can reach any part of the system or shared services that touch it. If it is truly isolated (internet-only with no route to the system), document that isolation with diagrams and firewall rules.

Can we meet AC-18(1) with WPA2-PSK?

A shared PSK provides encryption, but authentication is not attributable to an individual or managed device. If PSK is unavoidable for a limited use case, treat it as an exception, add segmentation and monitoring, and document a migration plan. ¹

How do we handle headless or IoT devices that can’t do interactive login?

Use device identity (commonly certificate-based auth) or an approved onboarding method through NAC, then isolate the device network so it only reaches required services. Document the device class, the auth method, and the segmentation controls.

What evidence is usually missing during an assessment?

Teams often lack controller configuration exports that show both authentication and encryption settings, plus proof those settings are consistent across sites. Keep dated exports, change tickets, and a current SSID inventory.

Are wireless access points themselves in scope?

Yes, because compromising AP/controller management can change authentication/encryption settings. Protect management access, restrict admin interfaces, and retain change control evidence for wireless infrastructure.

How should third-party-managed wireless be handled?

Treat the third party as part of the control implementation. Require contractual commitments to your wireless standard, request periodic configuration evidence, and validate segmentation at your boundary with your own testing.

Footnotes

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

2. NIST SP 800-53 Rev. 5