1Overview
AC.L2-3.1.17 completes the wireless pair. Where 3.1.16 requires that wireless access be authorized before a device connects, this control requires that the wireless access itself be protected, with authentication that confirms who is connecting and encryption that keeps the traffic from being read over the air.
The two wireless controls answer different questions. Authorization decides whether a device may join; protection decides how that connection is secured once permitted. A wireless network can require authorization and still expose its traffic if the encryption is weak or absent, and it can encrypt its traffic and still admit the wrong devices if the authentication is a shared secret. This control asks for both to be strong: authentication that identifies the connecting user or device, and encryption sufficient to protect the wireless traffic, which for an environment handling CUI means current, strong methods rather than the dated options many access points still permit. It connects to the cryptographic expectations of the framework, since wireless carrying CUI is held to the same strength standard as other protected traffic.
Protect wireless access using authentication and encryption.
The requirement names both elements plainly. "Authentication" here means the wireless network verifies the identity of what connects, ideally against the directory rather than through a shared key. "Encryption" means the wireless traffic is protected in transit using a strong method, so that a signal captured from outside the building cannot be read. Both are required together, because either alone leaves the wireless access exposed on the side the other would have covered.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.17 into two objectives: protect wireless access with authentication, and protect it with encryption.
Wireless access is protected using authentication. The wireless network authenticates the connecting user or device rather than admitting anything that presents a shared secret.
Wireless access is protected using encryption. The wireless traffic is encrypted with a strong, current method, so it cannot be read over the air.
The two objectives are authentication and encryption, and both must be strong. The common shortfall is meeting one and not the other: strong encryption paired with a shared-key authentication that identifies no one, or directory authentication running over an encryption setting that still allows a weak fallback. The assessor looks for both elements in current, strong form.
3Failure Patterns
The failures are about weak or dated protection and about the mismatch between strong authorization intentions and the actual wireless settings.
Pre-shared key as the only authentication
A wireless network protected solely by a shared password authenticates the key, not the user, so it satisfies neither the identity intent of authorization nor the authentication element of this control. Enterprise authentication tied to the directory is what turns wireless authentication into a verification of who is connecting, and its absence is the most common authentication shortfall.
Outdated encryption still enabled
Access points that still permit older encryption standards, or weak cipher options within a current standard, leave the wireless traffic decodable even where a strong method is also offered. Objective [b] expects current, strong encryption without a weak fallback, and a legacy option left enabled for an old device undermines the whole network.
The legacy device that holds the network back
An old piece of shop equipment that only supports weak wireless security is often the reason the whole network is configured down to its level. The resolution is to isolate that device on a separate, restricted network rather than to weaken the wireless protecting the CUI environment, so that one legacy machine does not set the security of everything.
Strong on paper, weak in negotiation
A wireless network may be described as using strong protection while its configuration still negotiates a weaker method with some clients, so the protection actually in force is below what the documentation claims. As with the remote-access encryption control, what matters is the protection negotiated in practice, not the strongest option available.
4Ownership
This is an IT and network-owned technical control, and its main demand is ensuring both authentication and encryption are strong and current, with legacy exceptions isolated rather than accommodated.
| Role | Responsibility for this control |
|---|---|
| IT and network lead | Configures enterprise authentication and strong, current encryption on the wireless network, removes weak methods, and isolates legacy devices that cannot meet the standard. Owns the configuration evidence. |
| Security or compliance lead | Confirms both authentication and encryption meet the strength expected for the CUI the wireless carries, connecting to the framework's cryptographic requirements. |
| Program lead | Includes wireless protection in periodic review, since standards advance and weak fallbacks are easy to leave enabled, and retains the configuration records. |
5Tooling
The control is delivered by the wireless configuration itself, using enterprise authentication and strong encryption, with legacy exceptions moved off the protected network.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | WPA2 or WPA3 Enterprise with 802.1X, RADIUS or Network Policy Server tied to the directory | Authentication of the connecting user or device against the directory, replacing a shared key with individual identity. |
| [b] | Current strong wireless encryption, weak methods and ciphers disabled | Strong encryption of the wireless traffic without a weak fallback, appropriate to the CUI carried. |
| Legacy handling | Separate isolated network for devices that cannot meet the standard | Keeping a legacy device that only supports weak security off the protected wireless, so it does not lower the whole network. |
| Verification | Wireless configuration review, negotiated-cipher checking | Confirming the authentication and encryption actually in force are strong, not merely available. |
The caveat mirrors the remote-access encryption control: what is negotiated matters more than what is offered. A wireless network that advertises strong protection while permitting a weak fallback protects at the weaker level for any client that uses it, so the control is verified by the protection in force. The assessor confirms both objectives by examining the wireless authentication and encryption configuration, looking specifically for weak methods left enabled.
6Evidence
The satisfied version of 3.1.17 shows strong authentication and strong encryption both in force on the wireless network.
| Evidence | What it demonstrates |
|---|---|
| Wireless authentication configuration | Objective [a]. Enterprise authentication tying wireless access to the directory rather than a shared key. |
| Wireless encryption configuration | Objective [b]. Strong, current encryption with weak methods disabled. |
| Legacy device isolation | Objectives [a], [b]. Evidence that devices unable to meet the standard are on a separate network, not weakening the protected one. |
| Negotiated protection verification | Objectives [a], [b]. Confirmation that the protection in force is strong, not merely the strongest available. |
The evidence should show both authentication and encryption in strong, current form and demonstrate that no weak fallback undercuts them, with any legacy exception isolated rather than accommodated on the protected network. Configuration showing directory-tied authentication and strong encryption, verified as the protection actually negotiated, is the clearest demonstration of the control.
One old device should not set the standard
The common wireless gap is a weak method left enabled for a single legacy machine, quietly lowering the protection for the whole floor. Isolating that device and bringing the wireless network to strong authentication and encryption is part of the onsite readiness work this practice does, usually alongside the wireless authorization work of the paired control.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.17. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.17[a] and 3.1.17[b]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov