AC-18(3): Disable Wireless Networking

AC-18(3) requires you to disable built-in wireless networking (for example Wi‑Fi, Bluetooth, NFC, cellular modems) on system components before you issue and deploy them, unless wireless is explicitly intended and approved for that component’s use. Operationalize it by defining “wireless allowed” configurations, enforcing them through build standards/MDM/GPO, and retaining proof of disablement per asset. ¹

Key takeaways:

• Treat embedded wireless as a default-deny feature; allow only with explicit business intent and authorization. ¹
• Make disablement part of issuance: imaging/build, MDM enrollment, and acceptance checks before a device reaches production users or environments. ¹
• Evidence is the control: auditors will ask for asset-scoped configuration proof, not just a policy statement. ¹

AC-18(3): disable wireless networking requirement is a deployment control, not a “security awareness” control. The point is simple: components often ship with wireless radios enabled by default, and those radios create unplanned entry points into your environment. You meet the requirement by ensuring wireless networking capabilities embedded within system components are disabled before you issue equipment to end users or deploy it into production, unless wireless is intended for use. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize AC-18(3) is to make it a gate in the lifecycle: procurement standards define what is acceptable, build standards disable what is not allowed, and issuance checklists verify the final state. The technical implementation often lives with endpoint engineering, network engineering, and datacenter/OT teams. Your job is to make the rule unambiguous, assign ownership, and require recurring evidence that demonstrates the disabled state across relevant asset classes.

This page gives you requirement-level guidance you can hand to operators, plus the evidence package you will need for assessments mapped to NIST SP 800-53 Rev. 5. ²

Regulatory text

Requirement (verbatim): “Disable, when not intended for use, wireless networking capabilities embedded within system components prior to issuance and deployment.” ¹

Operator interpretation: Before a device/component is put into service (issued to a user, racked in a datacenter, installed on a factory floor, deployed into a vehicle, etc.), you must disable any embedded wireless networking that you do not intend to use for that system. If wireless is intended, you need an explicit, documented exception that defines which wireless features are allowed and under what conditions. ¹

What counts as “wireless networking capabilities embedded within system components” in practice:

• Wi‑Fi radios (client and hotspot capabilities)
• Bluetooth/BLE
• NFC
• Cellular modems (LTE/5G), including eSIM
• Zigbee/Thread and other embedded short-range radios (common in IoT/OT)
• Wireless NICs in servers, workstations, printers, conference room devices, cameras, and appliances

Plain-English interpretation (what the control is trying to prevent)

Wireless interfaces create paths that bypass your wired network controls: they can connect to external networks, provide unintended bridging, enable rogue access points, or expand the attack surface through radios and drivers. AC-18(3) forces you to decide: “Do we need wireless here?” If the answer is no, disable it before the asset is deployed so “default-on” does not become “silently accepted.” ¹

Who it applies to

AC-18(3) is relevant anywhere NIST SP 800-53 is used as the control baseline, including:

• Federal information systems subject to NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down contractually (including in SSPs and security requirements). ²

Operational contexts where this control shows up during audits:

• Endpoint fleets (laptops, desktops, rugged devices)
• Datacenter builds (servers with embedded radios, KVM/management appliances)
• IoT/Facilities (printers, badges/readers, smart TVs, cameras)
• OT/industrial environments where wireless is prohibited or tightly controlled
• High-security zones (R&D labs, SCIF-adjacent spaces, regulated production lines)

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

Use this as an implementation runbook. The goal is repeatability and evidence.

Step 1: Define “intended for use” and create an allowlist

1. Write a wireless intent standard that answers:
   • Which asset types may have Wi‑Fi/Bluetooth/cellular enabled?
   • In which environments (corporate office, datacenter, OT, clean room)?
   • Under what management conditions (MDM enrolled, encrypted, approved SSIDs only)?
2. Create an exception path for legitimate needs (for example, approved Bluetooth for accessibility devices, approved cellular for field operations) with approver roles and required compensating controls. ¹

Deliverable: “Wireless Capability Intent & Exceptions Standard” (one page is fine if it is specific).

Step 2: Build an inventory view of wireless-capable components

1. Identify wireless-capable models from procurement records, EDR/MDM device attributes, and hardware catalogs.
2. Tag assets as “wireless-capable” even if disabled, so you can prove coverage and spot drift.
3. Include embedded components: USB Wi‑Fi dongles shipped with devices, built-in Bluetooth on desktops, cellular modules in rugged tablets.

Deliverable: “Wireless-capable asset register” or CMDB fields that support reporting.

Step 3: Implement disablement in the build/baseline (before issuance)

Implement the disablement mechanism appropriate to the platform:

• Windows endpoints

  • Disable Wi‑Fi and Bluetooth via GPO/MDM configuration profiles (where feasible).
  • Disable wireless adapters in Device Manager via policy-controlled settings where supported.
  • Block installation/use of unauthorized wireless adapters via device control where supported.

• macOS endpoints

  • Use MDM restrictions/configuration profiles to disable radios where supported.
  • Enforce “no new network interfaces without approval” through device management posture.

• Linux/workstations/servers

  • Disable drivers/modules for wireless chipsets when not needed.
  • Disable radio interfaces at the OS level and lock configuration management to prevent re-enablement.

• Servers/appliances/IoT

  • Disable wireless in BIOS/UEFI where possible.
  • Disable in vendor management interface, and change default settings before racking or handoff.
  • For devices where the radio cannot be disabled in software, document compensating actions (for example, physical removal of modules, disablement jumpers, or selecting non-wireless SKUs).

Deliverable: “Secure build standard: wireless disablement” per platform, tied to your endpoint engineering backlog.

Step 4: Make it a hard gate in provisioning and deployment

1. Add issuance checklist controls: device cannot be released until wireless state matches the standard.
2. Add deployment acceptance tests for datacenter/OT installs: confirm radios disabled before go-live.
3. Automate verification: compliance scripts, MDM compliance policies, or configuration management checks that report wireless state centrally.

Deliverable: “Provisioning/issuance checklist” plus “deployment acceptance checklist” with a wireless section.

Step 5: Monitor drift and enforce remediation

1. Detect re-enablement (user toggles Wi‑Fi on, BIOS reset, driver updates).
2. Auto-remediate where possible via MDM/GPO/config management.
3. Open tickets for non-compliant assets and record resolution.

Deliverable: Monthly (or assessment-period) compliance report showing wireless state for in-scope assets.

Step 6: Assign ownership and create recurring evidence

AC-18(3) fails in audits when nobody “owns” issuance. Assign:

• Control owner (GRC): defines requirement, exceptions, evidence cadence.
• Endpoint engineering / IT ops: enforces build/MDM policies and reports.
• Network/security engineering: validates wireless is not needed, supports NAC/Wi‑Fi design where allowed.
• Asset management/procurement: ensures purchasing aligns with the standard. ¹

Practical tooling note: Daydream is useful here when you need a single place to map AC-18(3) to an owner, a repeatable procedure, and the specific evidence artifacts you will collect every cycle so you do not rebuild the audit trail each year. ¹

Required evidence and artifacts to retain

Auditors typically accept a mix of policy, configuration, and proof-of-operation. Keep artifacts that show “prior to issuance and deployment” is real.

Minimum evidence set:

• Wireless intent standard + exception procedure (approved, versioned)
• Secure build/baseline documentation showing how each wireless capability is disabled per platform
• MDM/GPO/configuration management screenshots or exported settings showing disablement rules
• Issuance/deployment checklists with sign-off fields, including wireless verification
• Asset inventory report identifying wireless-capable devices and their compliance state
• Exception register (who approved, scope, compensating controls, review history)
• Sample device compliance outputs (command output, MDM compliance report, or EDR inventory fields) for a defined sample set

Evidence quality rule: show at least one artifact that proves the setting on devices, not only the intention in documents. ¹

Common exam/audit questions and hangups

Expect these questions and prepare direct, artifact-backed answers:

1. “What wireless capabilities exist in your environment?”
   Hangup: teams forget Bluetooth and cellular. Your inventory must explicitly include them.

2. “How do you ensure disablement happens before issuance?”
   Hangup: a policy dated last year does not prove issuance gating. Provide the checklist and a few completed records.

3. “Show me evidence on a sample of deployed assets.”
   Hangup: you can’t pull a report fast. Pre-stage a saved query or exported compliance report.

4. “How are exceptions handled and reviewed?”
   Hangup: informal approvals in chat. Use a ticketed workflow and keep an exception register.

5. “What about third-party-supplied appliances?”
   Hangup: “we don’t manage it” is not a control. Require configuration during implementation and retain acceptance evidence.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Disabling Wi‑Fi but leaving Bluetooth on.
  Fix: define wireless capabilities broadly in the standard; verify multiple radios during acceptance testing.

• Mistake: Relying on user behavior (“users shouldn’t turn it on”).
  Fix: enforce with technical controls (MDM/GPO), then monitor drift.

• Mistake: No proof tied to “prior to issuance.”
  Fix: add a provisioning gate and keep completed issuance records.

• Mistake: Exceptions without boundaries.
  Fix: time-bound exceptions, asset-scoped approvals, and compensating controls.

• Mistake: Procurement keeps buying wireless-capable SKUs for non-wireless areas.
  Fix: add procurement guardrails and approved hardware lists by environment.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific enhancement. Treat that as “no cited cases available here,” not “no risk.” The operational risk is straightforward: unauthorized wireless creates unmanaged connectivity paths and can violate system authorization boundaries, especially in restricted environments and contractor systems handling federal data. ¹

Practical 30/60/90-day execution plan

Use this as an operator-friendly rollout plan. Timelines are phases you can start immediately; adapt to your change windows and asset scale.

First 30 days (Immediate stabilization)

• Assign a control owner and technical owners; publish the wireless intent standard and exception workflow. ¹
• Identify in-scope asset classes and produce an initial wireless-capable inventory view.
• Implement disablement on new builds first (gold images, MDM enrollment profiles).
• Add wireless verification to issuance and deployment checklists.

Days 31–60 (Coverage expansion)

• Roll out enforcement to existing fleets through MDM/GPO/config management with a staged approach (pilot, then broader deployment).
• Stand up a recurring compliance report and define remediation SLAs through your ticketing system.
• Normalize third-party appliance onboarding: wireless configuration validated during implementation and documented in acceptance.

Days 61–90 (Assessment readiness)

• Run an internal mini-audit: sample assets, verify wireless state, verify exceptions, confirm issuance records.
• Close gaps: BIOS-level settings, edge cases (conference rooms, printers, lab devices), and drift detection.
• Package evidence into an assessor-ready folder mapped to AC-18(3), with screenshots/exports and sample outputs.

Frequently Asked Questions

Does AC-18(3) mean we must ban Wi‑Fi everywhere?

No. It requires you to disable wireless when it is not intended for use, and to do so before issuance and deployment. If Wi‑Fi is intended in some environments, document that intent and enforce it through controlled configurations. ¹

What counts as “prior to issuance and deployment” for laptops?

Treat it as “before the user receives the device for production work.” Your build process should disable disallowed radios, and your issuance checklist should verify the final state before handoff. ¹

Is disabling in the OS enough, or do we need BIOS/UEFI changes?

The requirement does not prescribe a specific layer. Use the strongest, most durable method available for the platform; for higher-risk environments, BIOS/UEFI disablement reduces drift from OS resets or reinstallation. ¹

How do we handle devices where the wireless radio cannot be disabled?

First, avoid those SKUs through procurement standards. If you inherit them, document a scoped exception and apply compensating controls (for example, selecting an alternate model at refresh, restricting physical placement, or disabling the function through vendor configuration where available). ¹

Does AC-18(3) apply to third-party-managed appliances and SaaS hardware?

It applies to system components you issue or deploy as part of your system boundary. For third-party-provided components, bake wireless disablement into implementation acceptance and retain evidence from the configuration step. ¹

What evidence is most persuasive to auditors?

A combination: the standard, the enforced technical configuration (MDM/GPO exports), and a device compliance report showing wireless disabled on a sample of in-scope assets. Completed issuance/deployment checklists help prove timing. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5