- Enumerate and authorize each wireless network with its purpose, and hunt rogue or forgotten SSIDs on a cadence.
- Use certificate- or credential-based enterprise authentication for networks that can reach CUI; keep guest and IoT wireless segmented away from it.
- Disable unused radios — Wi-Fi, Bluetooth — in build images and MDM profiles before devices are issued.
03.01.16 — Wireless Access
03.01 Access Control · NIST SP 800-171 Rev. 3
Requires establishing usage restrictions, configuration requirements, and connection requirements for each type of wireless access; authorizing each type of wireless access before connections are allowed; disabling wireless networking capabilities not intended for use prior to issuance and deployment; and protecting wireless access with authentication and encryption (aligned to SP 800-53 AC-18 with enhancements).
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗What this requirement is after
Wi-Fi that can reach CUI is a controlled entrance, not a convenience: each network is deliberately authorized, configured to a written standard, and protected with enterprise-grade authentication and encryption — and radios you do not intend to use are switched off before equipment reaches users. In practice that means certificate-based authentication on the corporate SSID, guest wireless isolated from everything, and no CUI over a shared-password network.
Merges Rev. 2's wireless authorization (3.1.16) and wireless protection via authentication and encryption (3.1.17) into one requirement, and adds an explicit expectation to disable wireless capabilities not intended for use before deployment.
Brilliant at the Basics practices that support this requirement
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Implementation considerations and evidence
- The authorized wireless network register with configuration standards
- Controller or access-point configuration exports showing authentication and encryption settings
- Build or MDM profiles disabling wireless capabilities not intended for use
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
Where this came from in Rev. 2
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |