AC-18 Wireless access: requirements and evidence

What AC-18 wireless access asks for and why it is hard to evidence

AC-18 requires the organization to set configuration requirements, connection requirements and implementation guidance for each type of wireless access, and to authorize each type before any connection to the system is allowed. The control is about deciding in advance which wireless access is permitted, how it must be built, and who approved it. It is selected in the low, moderate and high SP 800-53B baselines because unmanaged wireless access creates a path into a system that bypasses the perimeter controls built for wired traffic. An access point that someone installed without review, or a laptop that joins an open network, can expose internal traffic to interception or give an attacker a foothold inside the boundary. The privacy baseline does not select AC-18 because it is organized around processing of personally identifiable information rather than the network paths used to reach systems, although a system that processes PII still inherits AC-18 from the security baselines.

The configuration itself is usually the easier part. Most teams can document an approved SSID, an authentication method and an encryption standard. The harder part is proving that the documented wireless access is the only wireless access that exists. Assessors using the SP 800-53A procedures for AC-18 examine the configuration management plan, the wireless access authorizations and system audit records, and they interview the personnel who manage wireless connections. To pass, the organization needs a current inventory of access points and client connections, a record of the authorization for each wireless type, and logs that show when a new access point appeared or when a device connected. Reconciling those three sources is where many programs fail, because access points are often added by facilities staff, guest networks are managed by a separate team, and authorizations are not updated when hardware changes.

Before scoping this control, confirm with your assessor which wireless types are in the boundary, who owns the authorization record, and how rogue access point detection will be run and retained. Ask whether the moderate and high enhancements on authentication, encryption, disabling wireless networking, user configuration limits and transmission power are selected for your baseline, since AC-18(4) and AC-18(5) apply only at the high baseline. Network evidence from tools such as those listed on this page can support the inventory, but the organization still owns the authorization decisions, and an independent assessor decides whether the evidence is sufficient.

Which wireless networks, devices and teams AC-18 covers

AC-18 applies to every type of wireless access to the system, so the first job is listing those types and deciding which belong inside the authorization boundary. Each card below is a scoping decision, component or owner that changes the evidence an assessor will ask for, and most of them depend on the system's impact level and the baseline it is assessed against.

Corporate Wi-Fi in the system boundary

Corporate wireless networks that carry staff traffic to or from the system are the most common case. Decide whether the wireless segment is part of the system boundary or is an external network that connects through a controlled boundary, because that decision determines whether AC-18 evidence covers the access points themselves. Record the SSIDs, authentication method and the access points that serve the system's users, and confirm each one has a documented authorization before any connection is allowed.

Guest networks and their connection to the system

Guest wireless is often treated as outside scope, but it is in scope if any path connects it to system resources, shares a controller or uses the same VLAN trunks. Ask the network team to show the segmentation between guest and corporate networks, and document whether guest devices can reach any system component. An assessor will expect the guest network to appear in the wireless access inventory, even if the conclusion is that it is excluded.

Wireless printers and sensors

Printers, badge readers, environmental sensors and similar devices often join wireless networks without an owner in the security team. Each device type that connects wirelessly to a system component is a separate type of wireless access that needs configuration requirements and authorization. Build an inventory that names the device class, the network it joins, and who approves it, and flag any device that cannot meet the configuration requirements you set.

Building management radios

Facilities teams often run wireless building controls, such as HVAC, lighting or access systems, on radio networks managed outside IT. Where those radios share infrastructure, or reach the system's network, they fall within AC-18. Confirm with facilities which protocols are in use, which gateways bridge them to IT networks, and whether the vendor can apply the configuration and authentication settings your baseline requires.

Contractor and vendor devices

Laptops, handheld tools and diagnostic devices brought in by contractors or vendors are a distinct type of wireless access, because the organization may not control their configuration. Decide whether they may connect at all, and if so, which networks they may use and what the connection requirements are. Record how these devices are authorized, how long the authorization lasts, and who removes it when the engagement ends.

Owners of access points, controllers and identity

Responsibility for AC-18 is usually split across network operations, the team that runs wireless controllers, and the identity team that manages the authentication integration. Name one accountable owner for the authorization record, and document who maintains the controller configuration and who manages certificates or directory links. Without this split documented, configuration changes can bypass the authorization step that AC-18 expects.

Scope by impact level and baseline

AC-18 is selected in the low, moderate and high baselines, but the enhancements are not. AC-18(1) and AC-18(3) appear in moderate and high, while AC-18(4) and AC-18(5) appear in high only. Confirm the system's impact level first, because it determines which enhancements you must evidence, and then decide how far the wireless scope extends. Tailoring can change this, so record any approved deviation in the system security plan.

How an assessor tests AC-18 and what they ask to see

This table maps each part of the SP 800-53A assessment for AC-18 to the method used, the people or artifacts involved and the evidence an assessor expects to see. Read it as a checklist of what to have ready before an assessment starts, since a gap in any row is a likely finding.

Assessment element	What the assessor does	Evidence to have ready
Determination statements (4)	Tests whether each statement holds: configuration requirements, connection requirements and implementation guidance exist for each wireless type, and each type is authorized before connection.	Written wireless configuration and connection requirements, implementation guidance, and a dated authorization for each wireless type in use
Examine: configuration management plan	Checks that the plan covers wireless access settings and that wireless configurations are managed under it.	Configuration management plan section on wireless, baseline settings for access points and clients
Examine: wireless access authorizations	Compares the authorization records against the wireless types actually present on the system.	Authorization records per wireless type, with approver, date and scope, matched to current connections
Examine: system audit records	Looks for logs showing wireless connections, authorization checks and changes to wireless settings.	Audit records for wireless association, authentication events and configuration changes, retained per the audit policy
Interview: personnel managing wireless connections	Asks administrators how wireless types are approved, how connections are restricted and how unauthorized access is detected.	Staff able to explain the approval path, the configuration baseline and the response to a rogue access point
Test: wireless access management capability	Attempts or observes connections to confirm that unauthorized wireless types are blocked and authorized ones follow the requirements.	Test results from a controlled connection attempt, with screenshots or logs and the tester's notes
Common finding: missing authorization	A wireless type is in use, such as a guest network or a newly added access point model, with no recorded authorization.	Inventory of wireless types reconciled against authorization records, reviewed on a set schedule
Common finding: stale configuration requirements	Documented requirements do not match the configuration on live access points or client profiles.	Configuration comparison or scan output showing drift, with the remediation record

Implementing AC-18 in order: from wireless inventory to authorized connections

This sequence takes an organization from an unknown set of wireless connections to a documented, authorized and monitored wireless posture, with each step producing the record an assessor will examine for AC-18.

Inventory every wireless access type
The network and facilities teams list each wireless access type in scope: corporate Wi-Fi, guest networks, wireless peripherals, wireless management interfaces, and any radio links used by OT or building systems. Record the system each type reaches, the owner, and where the access point or controller sits. The step is done when the inventory covers every wireless path into the system boundary and the owner of each entry has signed off. Confirm the boundary with the system security plan, since an unlisted access type is the most common gap an assessor finds.
Write configuration and connection requirements per type
For each inventoried type, the security owner writes the configuration requirements (encryption mode, SSID handling, certificate use, management access) and the connection requirements (who may connect, from which device classes, and under what conditions). Implementation guidance tells administrators how to meet them. Keep one requirement set per access type so that a guest network and a corporate network are not governed by the same text. The output is a configuration standard document approved by the owner of the system, ready for assessors to examine.
Record prior authorization for each access type
AC-18 requires that each wireless access type be authorized before any connection is allowed, so the authorizing official approves each type by name and date against the requirements from the previous step. Store the approvals with the configuration standard and link them to the system security plan. Re-approval is needed when a type's requirements change. The step is complete when every inventoried type has a signed authorization that predates its first connection, and an assessor can match each access point to an approved type.
Enforce the rules on the network
Engineers translate the approved requirements into controller settings, access point profiles, and perimeter rules, then remove any radio or SSID that has no authorization. Where wireless traffic reaches internal segments, firewall rules and aliases should restrict it to the approved destinations. Test each enforcement point by attempting a connection that the standard prohibits and confirming it fails. Save the configuration exports and test results as evidence. Consider how AC-18 interacts with AC-2, AC-3, IA-2 and CM-7, because the same settings usually support those controls too.
Enable monitoring and logging of wireless access
Configure the controller and network sensors to log association, authentication, and rejected connection events, and forward them to the central log platform. Self-hosted tools such as OPNsense (for firewall rule match logging), Suricata (EVE JSON alerts and protocol records) and Zeek (conn.log and related logs) can help correlate traffic that crosses the wireless boundary, though whether a given wireless controller exposes these events is a point to confirm in the vendor documentation. The step closes when a test connection produces a traceable record in the log platform and someone has reviewed the sample.
Decide which enhancements the baseline selects
Check the chosen SP 800-53B baseline. AC-18(1) and AC-18(3) apply at moderate and high, while AC-18(4) and AC-18(5) apply only at high, and the privacy baseline does not select AC-18 at all. AC-18(2) is withdrawn and is not part of the current set. For each selected enhancement, document how the organization meets it: encryption and authentication for AC-18(1), a documented way to disable wireless networking for AC-18(3), user configuration limits for AC-18(4), and antenna and transmission power settings for AC-18(5). Record the decision and any tailoring in the system security plan so that the final assessment has a complete answer for each item.

Evidence that passes AC-18 and how to keep it current between audits

An assessor testing AC-18 wants to see that each type of wireless access was defined, authorized and actually configured as authorized, and that the record still holds on the day of the test. The cards below cover the artifacts that usually carry that proof and the routine that keeps each one accurate between assessments. The organization owns these records; an implementation partner can help prepare and automate them, and only the independent assessor reaches a finding.

Configuration requirements document

This is the written statement of configuration and connection requirements, and implementation guidance, for each type of wireless access the organization allows. Assessors start here because the determination statements require the requirements to exist before any connection is authorized. Check that it names each wireless type, the required encryption and authentication settings, and the owner who approves changes. Review it at a set interval and whenever the wireless design changes, and record the review date in the document itself.

Per-type wireless authorizations

Each wireless access type needs its own authorization record showing who approved it, the approval date, the scope of systems it reaches and any expiry or review trigger. Assessors compare these records against the systems they see connecting wirelessly, so a single blanket approval rarely satisfies the requirement. Keep the approvals in the same register as other access authorizations so changes are traceable. Ask whether each authorization names an accountable approver and whether it is revisited when the wireless design changes.

Wireless configuration exports

Exports of the access point and controller settings show the configuration in force, not the configuration intended. Schedule exports from each managed controller and store them with timestamps so an assessor can see settings over time. Compare each export with the configuration requirements document and flag drift. Where the wireless platform is self-hosted, confirm that the export format and frequency are documented, since the vendor's default export behavior varies by product.

Network rules for wireless segments

Firewall and segmentation rules that control what wireless clients can reach show how the authorization is enforced on the network. Assessors look for rules that match the approved wireless types and deny the rest by default. Export the rule set on a schedule, keep a change history, and tie each rule change to an approved request. On OPNsense, rule aliases and per-rule logging make the rule set easier to review, but the organization still has to show that the rules match the authorizations.

Audit records of connection attempts

Logs of wireless association, authentication and denial events show whether connections followed the authorized path. Retain these records long enough for the organization's own review cycle and forward them to a central log store where analysts can search them. Assessors often sample a few days of records and ask for matching authorizations, so confirm that the identifiers in the logs can be traced to a named device or user. Zeek connection logs and Suricata EVE records can add network-side context, but they do not replace the access point's own association records.

Records of disabled wireless capability

Where a wireless capability is disabled, the organization should keep a record that names the systems affected, the method used to disable it and the verification performed afterward. Assessors check these records where the disabling enhancement applies to the baseline in use. Verification evidence, such as a configuration export showing the radio off or a scan showing no broadcast, is more persuasive than a change ticket alone. Recheck the disabled state on a schedule, because a firmware update or a new access point can quietly re-enable it.

How self-hosted open-source tools produce AC-18 evidence

OPNsense is a firewall platform licensed under BSD-2-Clause. For AC-18, its value is in showing how traffic from wireless segments is permitted or denied. Rules pass, block or reject traffic by source, destination, port and protocol, so a wireless segment can be separated from internal networks and limited to the services it was authorized to reach. Aliases group addresses, which helps keep rule sets tied to the authorized wireless populations rather than to individual hosts.

Segmentation rules: Export the rule set for each wireless interface or VLAN and compare it with the configuration requirements in the wireless access documentation.
Aliases: Show which address groups represent authorized wireless devices or user populations, and when those groups changed.
Logged rule matches: Enable logging on rules that govern wireless traffic so matches can be reviewed in the live log view.
Change history: Pair rule exports with the change records that approved each modification.

What it cannot prove alone: OPNsense does not show whether a wireless connection was authorized in advance, which access point or client authenticated, or whether a rogue access point exists. Confirm with the vendor and in your own environment whether it manages wireless controllers or radios directly, and which wireless-specific capabilities your deployment actually uses. Keep the firewall records alongside authorization and wireless management evidence.

What meeting AC-18 costs in money and effort

This table breaks the cost of meeting AC-18 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since NIST does not estimate compliance costs and no figures for this control are supplied here. The main takeaway is that most of the effort sits in the wireless configuration and authorization records, so the scope of wireless types and sites matters more than any single tool.

Cost component	Who is paid, one-time or recurring	What drives it up or down
Wireless configuration and documentation	Internal staff or implementation partner for the configuration requirements and implementation guidance for each wireless type; one-time, then updated on change	Number of wireless types and SSIDs, number of controller platforms, and whether standards already exist in the configuration management plan
Authorization workflow	Internal approvers and system owners to authorize each wireless type before connections are allowed; recurring with each new type or change	Number of approvers, whether requests are tracked in an existing ticketing or identity workflow, and how often sites add new access points
Network enforcement and logging	Internal network engineers or a partner for segmentation, access rules and wireless event logs; one-time build, recurring tuning	Number of sites and controllers, use of existing firewall and intrusion detection tooling, and how much logging is already in place
Monitoring and log storage	Internal operations or a managed service, plus storage; recurring	Log volume, retention period set by the organization, and whether self-hosted log tools already store records for other controls
Identity and authentication integration	Internal identity team for certificate or directory-backed authentication under the enhancement on authentication and encryption; one-time, then recurring administration	Whether wireless authentication reuses the existing identity provider and certificate authority, and whether the high baseline enhancements apply
Assessor testing	Independent assessor paid for examine, interview and test activities; typically one-time per assessment cycle	Number of wireless types sampled, number of sites visited, and quality of evidence prepared in advance
External review or penetration testing	Security testing provider, if the organization buys wireless testing; optional, recurring on the organization's schedule	Whether wireless testing is in scope, number of sites, and whether results feed into the plan of action and milestones
Open-source tooling licenses	No license fee for the listed open-source components; staff time and hosting are still paid	Reuse of existing firewall, log and identity platforms lowers the new spend; a new self-hosted stack adds operating effort

Who owns AC-18 and what an implementation partner or auditor does

Your organization owns AC-18. That means your leadership decides which types of wireless access are permitted, who authorizes each type before a connection is allowed, and who accepts the residual risk when a configuration cannot meet a requirement. The control asks for configuration requirements, connection requirements and implementation guidance for each type of wireless access, and for authorization of each type before connections are made. None of those decisions can be delegated to a vendor.

Authorization decisions: Named officials approve each wireless type, such as corporate Wi-Fi, guest networks or wireless peripherals, and keep records of the approvals.
Requirements ownership: Security and network leads write the configuration and connection requirements, then maintain them as the environment changes.
Policy alignment: Wireless rules should match the access control policy and procedures and the system security plan for the system in scope.
Residual risk: Accepted deviations are documented with an owner, a rationale and a review date.
Operational records: Your teams keep the authorization records, configuration baselines and change history that assessors will examine.

Before engaging any partner, confirm internally who holds each authorization and where the records live, because an implementation partner cannot approve a wireless type on your behalf.

Where organizations fall short on AC-18 and how to close each gap

Most AC-18 findings come from wireless access that exists outside the documented plan, not from missing policy text. The gaps below cover authorization, configuration evidence, network separation, high baseline user limits and log correlation, each with a check an assessor can repeat.

Unknown wireless devices outside the list

Access points and client devices are often added by facilities teams or departments without a record in the approved inventory. AC-18 expects each type of wireless access to be authorized before connections are allowed, so an unlisted access point is an authorization gap even if it is encrypted. Reconcile wireless controller and switch data against the inventory, and ask who may add a device and how that addition is recorded. Look for rogue access points during periodic site surveys and treat any unmatched radio as an incident until it is classified.

Authorizations that skip wireless types

A single general statement that wireless is permitted does not authorize each type of wireless access separately, which is what the control asks for. Staff Wi-Fi, guest access, wireless printers, and wireless-enabled maintenance tools each need their own configuration requirements, connection requirements and authorization record. Ask for the authorization register and confirm that every type in the configuration management plan has a matching entry with an approver and a date.

Configuration exports never retained

Teams often export wireless controller settings only when troubleshooting, so assessors find no dated baseline to compare against. Retain configuration exports on a schedule and after each approved change, stored under configuration management with version history. Compare the current export with the authorized baseline and record any drift. Open-source controllers and configuration management tools can produce these exports, but you should confirm each product's export format and retention options in your own environment.

Guest networks reachable from internal segments

Guest wireless is often bridged onto a VLAN that can reach internal file shares, management interfaces or the production network. This breaks the connection requirements that AC-18 expects for each wireless type and weakens boundary protection controls that sit alongside it. Test from a guest client that internal addresses, management ports and service ports are unreachable. Firewall rules such as those in OPNsense can enforce this with aliases for internal ranges, and each rule match can be logged for review.

No review of user configuration limits

AC-18(4) applies at the high baseline and restricts whether users may change wireless configurations. Where users can alter radio settings, channels or security options on their own devices, the organization has no enforced limit and no evidence of review. Ask who holds administrative rights on wireless clients and whether those rights are reviewed on a defined cycle. Check that managed endpoints block user changes to wireless profiles, and document each exception with its approver.

No link between wireless and audit logs

Wireless authentication events, rogue detections and association records often sit in controller logs that never reach the central audit trail. Without that link, an assessor cannot follow a wireless session from authentication to network activity. Forward controller logs to the same store as authentication and network logs, and use a shared identifier such as the user or device record where possible. Zeek's conn.log and Suricata's EVE output can then tie network sessions to the wireless events that preceded them, which you should validate in your own deployment.

What buyers ask about AC-18 cost, effort and outside help

How long does it take to implement AC-18 and what does it need from our team?

No supplied figure gives a duration for AC-18, and NIST does not set implementation timelines for SP 800-53; it leaves that to the authorizing body and OMB Circular A-130. The effort depends on how much wireless access your system actually uses. Some systems need only a documented decision that wireless is prohibited, while others need configuration requirements, authorizations and monitoring for each wireless type. Your team will need to supply the inventory of wireless networks and devices, the people who manage them, and access to configuration records. Ask any partner to confirm the duration in writing against the scope of wireless types you define.

Can we implement AC-18 in-house without an outside partner?

Yes, an organization can implement AC-18 with its own staff, because the organization owns its controls. The work is largely documentation and configuration: defining each type of wireless access, setting its configuration and connection requirements, recording prior authorizations, and showing that the settings are in place. Outside help is most useful for systems engineering, hardening and evidence collection, which can be slow when staff are already busy. Whichever route you choose, an independent assessor, not the implementer, decides whether the control is met.

What should a partner's written scope list for AC-18 work?

A written scope should name each wireless access type in your environment, the configuration and connection requirements for each, and the authorization record that approves it. It should list the systems and sites covered, the enhancements in your baseline, and the evidence to be produced, such as configuration exports, authorization records and audit logs. It should state which deliverables your team must review and sign off, and what happens to work that falls outside the agreed scope. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides a quote from that scope.

Which AC-18 enhancements do the moderate and high baselines add?

The moderate and high baselines both select AC-18(1), which covers authentication and encryption for wireless access, and AC-18(3), which covers disabling wireless networking when it is not needed. The high baseline adds AC-18(4), which restricts configuration changes by users, and AC-18(5), which covers antennas and transmission power levels. The low baseline selects only the base control. Confirm these selections against the current SP 800-53B profiles for your impact level before you scope the work.

What evidence will an assessor accept for AC-18?

An assessor will look for evidence that matches the SP 800-53A procedure: the configuration management plan, the wireless access authorizations, and system audit records, along with interviews with the people who manage wireless connections and a test of the wireless access management capability. Documents alone rarely satisfy the test step, so you should expect to demonstrate live settings. Assessors will not accept an undated policy, an authorization that does not match the configuration in place, or a claim that wireless is disabled without evidence. Confirm the exact assessment expectations with your assessor before collecting evidence.

Which parts of AC-18 do organizations usually outsource?

Organizations commonly outsource the configuration review, the hardening of wireless controllers and gateways, and the collection of evidence in a consistent format. Some also outsource security testing of the wireless environment. Authorization decisions and policy ownership usually stay in-house, because they are accountable management decisions. An independent assessor always performs the formal assessment, and DeployOpen does not issue audit reports or certifications.

How do open-source tools help produce AC-18 evidence?

Self-hosted tools can record what happens on the network, which supports the audit and test steps. OPNsense rules can restrict traffic by source, destination, port and protocol, and log each rule match for review. Suricata's EVE output and Zeek's conn.log record connections and protocol activity that can be retained for review. These tools support monitoring but do not replace the wireless authorization records or configuration management plan that the assessor examines. Confirm each tool's wireless-specific capability in your own environment before relying on it as evidence.

How DeployOpen scopes, implements and prepares AC-18 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so wireless access controls for AC-18 are scoped, configured and recorded in your environment. We prepare systems and evidence for your assessor, while your organization owns the control decisions and an independent assessor issues any findings.

How we scope

We confirm which wireless access types exist in your environment and which baseline your system falls under.
The written scope lists each wireless type, its authorization owner and the AC-18 enhancements selected for your baseline.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure wireless access requirements and connection settings on the open-source platforms in scope, as your policies define them.
We set up authentication, encryption and wireless disablement settings where the selected enhancements require them.
We configure logging of wireless connection events so that authorization records can be traced to system audit records.

How we test

We run configuration checks against the written requirements and record the results for each wireless access type.
We test whether unauthorized wireless connections are blocked and whether attempts generate alerts or log entries.
We document test results so your team can compare them against the four SP 800-53A determination statements for AC-18.

How we hand over and support

We deliver configuration documentation, authorization records and test evidence in a format your assessor can examine.
We document the operating procedures your staff need to keep wireless settings and authorizations current after handover.
Ongoing support, upgrades and continuous testing are available as a retainer, and your organization keeps ownership of its controls.