3.1.17Protect wireless with authentication and encryption in Rev. 3
Withdrawn and incorporated elsewhere: 03.01.16 Wireless Access.
Status as of 2026-09-08
Rev. 2 is what a contract requires today. DFARS 252.204-7012 and the CMMC rule at 32 CFR 170 point at NIST SP 800-171 Rev. 2, and a standing DoD class deviation keeps it there. NIST has published Rev. 3, but publishing a revision does not change an obligation. A move to Rev. 3 would arrive through the Department's reform process and formal rulemaking, a change to that deviation or an amendment to the rule, not through publication. The Department has published its organization-defined parameter values for Rev. 3 in preparation; that is groundwork, not adoption.
Side by side
Rev. 2 · in force 3.1.17 Wireless Access Protection
Assessment objectives · 800-171A
- [a] wireless access to the system is protected using authentication
- [b] wireless access to the system is protected using encryption
Rev. 3 · not adopted 03.01.16 Wireless Access
a. Establish usage restrictions, configuration requirements, and connection requirements for each type of wireless access to the system.
b. Authorize each type of wireless access to the system prior to establishing such connections.
c. Disable, when not intended for use, wireless networking capabilities prior to issuance and deployment.
d. Protect wireless access to the system using authentication and encryption.
Determination statements · 800-171A Rev. 3
- 03.01.16.a[01] each type of wireless access to the system is defined.
- 03.01.16.a[02] usage restrictions are established for each type of wireless access to the system.
- 03.01.16.a[03] configuration requirements are established for each type of wireless access to the system.
- 03.01.16.a[04] connection requirements are established for each type of wireless access to the system.
- 03.01.16.b each type of wireless access to the system is authorized prior to establishing such connections.
- 03.01.16.c wireless networking capabilities not intended for use are disabled prior to issuance and deployment.
- 03.01.16.d[01] wireless access to the system is protected using authentication.
- 03.01.16.d[02] wireless access to the system is protected using encryption.
Left: NIST SP 800-171 Rev. 2 and 800-171A, verbatim. Right: NIST SP 800-171 Rev. 3 and 800-171A Rev. 3, verbatim, with organization-defined blanks highlighted.
Word by word
The Rev. 2 requirement compared with its Rev. 3 successor. A mechanical comparison of the two verbatim texts, not an interpretation.
removed in Rev. 3 added in Rev. 3
Rev. 2 3.1.17 → Rev. 3 03.01.16 Wireless Access
7 words kept, 0 removed, 48 added. Rev. 3 statement labels omitted for the comparison.
What NIST says changed
Rev. 3 withdraws this requirement as a separate item and folds it into another requirement. NIST's note: Incorporated into 03.01.16.
NIST's Rev. 3 discussion for 03.01.16
Wireless networking capabilities represent a significant potential vulnerability that can be exploited by adversaries. Establishing usage restrictions, configuration requirements, and connection requirements for wireless access to the system provides criteria to support access authorization decisions. These restrictions and requirements reduce susceptibility to unauthorized system access through wireless technologies. Wireless networks use authentication protocols that provide credential protection and mutual authentication. Organizations authenticate individuals and devices to protect wireless access to the system. Special attention is given to the variety of devices with potential wireless access to the system, including small form factor mobile devices (e.g., smart phones, tablets, smart watches). Wireless networking capabilities that are embedded within system components represent a potential vulnerability that can be exploited by adversaries. Strong authentication of users and devices, strong encryption, and disabling wireless capabilities that are not needed for essential mission or business functions can reduce susceptibility to threats by adversaries involving wireless technologies.
What this means for you now
Nothing changes in what you are assessed against until a class deviation or a published rule adopts Rev. 3. Keep meeting 3.1.17 as written in Rev. 2.
Bedrock CMMC shows this same comparison against your own package, with your current status on the Rev. 2 side, so the day adoption lands the migration is a review, not a rewrite.
Where this page's facts come from
- Rev. 2 text and objectives
- bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.basicRequirement@rev2; bedrock-cmmc-api@89b8e8e:migrations/005_reference_objectives.sql#AssessmentObjective.description@rev2
- Mapping and change class
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/r2_r3_transition_map.json#r2_to_r3
- Rev. 3 03.01.16
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/rev3.json#requirements[]