By The Defense Compliance Report Editorial Team Last reviewed: August 2026 · Last verified: August 21, 2026
Editorial research — not formally reviewed by a CMMC Subject Matter Advisor.
The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with the Cyber AB, the Department of War, the Department of Defense, DCMA DIBCAC, NIST, or any U.S. government agency. This is educational research, not legal, contractual, cybersecurity, or compliance advice.
Current program status — verified August 21, 2026. The CMMC wireless security requirements on this page remain tied to NIST SP 800-171 Revision 2. CMMC Phase 1 began November 10, 2025, and the original rule schedule runs it through November 9, 2026. On July 13, 2026, the Department of War suspended the transition to Phase 2 and all later implementation milestones. During the suspension, new procurement designations are limited to Level 1 (Self) and Level 2 (Self), while select government-led assessments may continue. CMMC Level 2 remains tied to NIST SP 800-171 Revision 2; Level 2 self-assessment results and annual affirmations still go into SPRS when the contract requires that status; and DFARS 252.204-7012 safeguarding duties remain in force. The four-phase schedule is still printed in 32 CFR Part 170. The implementation of Phase 2 is what was suspended. None of the wireless requirements below changed. Official suspension procedures · 32 CFR § 170.3
CMMC wireless security requirements sound bigger than they are.
Two requirements in CMMC Level 2 have the word “wireless” in them. Both are worth five points. Neither one can go on a plan of action.
That is the entire rule. It is smaller than almost anything else you will read on this subject.
The decision behind it is much bigger — and that gap is where contractors lose money, either by replacing a network they did not need to replace, or by passing a self-assessment they should not have passed.
The short answer
CMMC wireless security requirements at Level 2 come down to two controls: AC.L2-3.1.16 (authorize wireless access before allowing the connection) and AC.L2-3.1.17 (protect wireless access using authentication and encryption). Each is worth 5 points under 32 CFR § 170.24, and § 170.21 does not allow either one on a CMMC POA&M. That is 10 non-deferrable points. 32 CFR § 170.24 · 32 CFR § 170.21
What changes the answer for you is whether Controlled Unclassified Information (CUI) actually crosses your Wi-Fi. If it does, more than a dozen adjacent requirements — identity, FIPS-validated cryptography, external connections, mobile devices, boundary protection, and evidence — can be implicated by how the network is built. If it does not, and the separation is real and testable, most of this collapses to proving that it stays that way.
And here is the part that surprises people, including some consultants advising them: the official CMMC Level 2 Assessment Guide includes a small-company example using WPA2 with a pre-shared key on a wireless network that may transmit CUI — and marks both AC.L2-3.1.17 assessment objectives satisfied. We will show you exactly where that example lives, what it authorizes, what it does not prove, and why the surrounding requirements can still make a shared-key design expensive to defend. CMMC Assessment Guide – Level 2, pp. 52–53
Who this page is for
Read this if you:
- Run a Level 2 contractor with company Wi-Fi and you are writing or defending your System Security Plan (SSP)
- Were told your access points “are not FIPS validated” and you are deciding whether to buy new ones
- Have remote workers on home or public Wi-Fi and no clear answer on scope
- Have a shop floor with wireless tablets, scanners, printers, or CNC controllers
- Are an MSP or internal IT lead assembling wireless evidence before a self-assessment
Skip this page if you:
- Only handle Federal Contract Information (FCI) and not CUI — no Level 1 requirement names wireless. Start with our CMMC Level 1 self-assessment checklist instead.
- Are looking for a list of “CMMC-certified” access points. No such product list exists. FIPS validation applies to a cryptographic module and its validated configuration, not to a marketing label on an access point.
- Need your solicitation, contract clause, or flow-down interpreted. Ask the contracting officer or prime for the written requirement, and use a qualified federal-contracts attorney for legal interpretation. A Registered Practitioner can help map the resulting requirement to scope, controls, and evidence.
The first-screen verdict
| Question | Direct answer |
|---|---|
| Is Wi-Fi allowed under CMMC Level 2? | Yes. Wireless access must be authorized before connection and protected with authentication and encryption. There is no wireless ban. |
| Is WPA3 required? | No. No CMMC Level 2 requirement names WPA3. |
| Is 802.1X or RADIUS required? | No. The official guide discusses pre-shared-key and enterprise approaches. Neither technology is mandated by name. |
| Can WPA2 with a shared password satisfy AC.L2-3.1.17? | Potentially yes. The official guide includes that exact small-company example. A shared key does not, by itself, prove individual identity, authorization, or offboarding. |
| Does joining the Wi-Fi itself require multi-factor authentication? | No. No requirement places MFA at SSID association. IA.L2-3.5.3 still applies to the covered privileged and non-privileged account access paths. |
| Must the access point itself be FIPS validated? | Only when its cryptographic module is the layer protecting CUI confidentiality. In an end-to-end VPN or locked-down VDI design, the evidence obligation may move to that layer. |
| Is guest Wi-Fi automatically out of scope? | No. Separation has to be real and testable, not just a different SSID. |
| Can a wireless gap go on a POA&M? | The two wireless-named requirements cannot. A narrow POA&M path exists for SC.L2-3.13.11 when encryption is used but is not FIPS validated; AC.L2-3.1.20 is a 1-point requirement that the rule separately forbids on a POA&M. |
Which CMMC wireless security requirements apply at Level 2?
Two CMMC Level 2 requirements name wireless directly: AC.L2-3.1.16 and AC.L2-3.1.17. Both come from NIST SP 800-171 Revision 2. Both carry a 5-point value under 32 CFR § 170.24. Up to 18 adjacent requirements can be implicated by the architecture even though they do not all mention wireless. Which findings are actually in play depends on the asset category, the CUI path, and the evidence — not on a blanket “Wi-Fi equals X points” formula.
The regulation explains its scoring logic: five points go to listed requirements whose absence could lead to significant network exploitation or CUI exfiltration; three points go to listed requirements with a specific and confined effect. 32 CFR § 170.24(c)(2)
The two that say “wireless”
| Requirement | What it requires | NIST class | Points | POA&M eligible? |
|---|---|---|---|---|
| AC.L2-3.1.16 | Authorize wireless access prior to allowing such connections | Derived | 5 | No |
| AC.L2-3.1.17 | Protect wireless access using authentication and encryption | Derived | 5 | No |
Ten points. Neither deferrable.
Here is the detail almost nobody publishes: AC.L2-3.1.16, AC.L2-3.1.17, and AC.L2-3.1.18 appear consecutively in the CFR’s list of 5-point derived requirements. The official assessment guide also calls the three requirements complementary because they control wireless and mobile-device connections through authorization, authentication, and encryption. Three requirements, fifteen points, no CMMC POA&M path. 32 CFR § 170.24(c)(2)(i)(B)(1)(ii) · CMMC Assessment Guide – Level 2, p. 53
The requirements your wireless design can implicate
| Requirement | Why the wireless design matters | Points | POA&M eligible? |
|---|---|---|---|
| AC.L2-3.1.18 | Controlling mobile-device connections | 5 | No |
| AC.L2-3.1.19 | Encrypting CUI on mobile devices | 3 | No |
| SC.L2-3.13.11 | FIPS-validated cryptography when cryptography protects CUI confidentiality | 5, or 3 when encryption is present but unvalidated | Only the specific 3-point condition |
| SC.L2-3.13.8 | Cryptographic protection of CUI in transmission | 3 | No |
| SC.L2-3.13.5 | Separating publicly accessible system components; not a universal “guest SSID control” | 5 | No |
| IA.L2-3.5.1 / IA.L2-3.5.2 | Identifying and authenticating users, processes acting for users, and devices | 5 each | No |
| IA.L2-3.5.10 | Cryptographically protecting stored and transmitted passwords | 5 | No |
| AC.L2-3.1.1 / AC.L2-3.1.2 | Limiting system access to authorized users, processes, devices, transactions, and functions | 5 each | No |
| CM.L2-3.4.6 / CM.L2-3.4.7 | Least functionality; restricting nonessential functions, ports, protocols, and services | 5 each | No |
| SC.L2-3.13.1 / SC.L2-3.13.6 / SC.L2-3.13.15 | Boundary protection, deny-by-default network communications, and communications-session authenticity | 5 each | No |
| AC.L2-3.1.12 / AC.L2-3.1.13 | Monitoring, controlling, and cryptographically protecting remote-access sessions | 5 each | No |
| AC.L2-3.1.20 | Verifying and controlling connections to external systems, including remote-work architectures where applicable | 1 | No — expressly excluded by § 170.21(a)(2)(iii) |
The finding that should change how you plan
NIST SP 800-171 Revision 2 contains 110 security requirements across 14 families. We counted the score categories in § 170.24: 42 requirements are listed at 5 points, 14 are listed at 3 points, two have the special 3-or-5 partial-credit treatment, and the remaining 52 are worth 1 point. The Access Control family contains thirteen of those 1-pointers.
The cheap-looking exception is AC.L2-3.1.20. It is worth one point, but § 170.21(a)(2)(iii) names it as one of six requirements that may never appear on a CMMC POA&M.
Practically: there is no “we will fix the two wireless controls after the assessment” option. A single unmet 5-pointer removes the conditional path even if the arithmetic score is otherwise high. You can be at 105 out of 110 and still fail to qualify for Conditional Level 2 because the missing requirement is not POA&M eligible.
One honest caveat before you panic-add the entire table. Each requirement is assessed against its own applicable objectives. One bad Wi-Fi configuration does not automatically trigger every deduction above. The ledger shows which requirements the architecture can implicate and which findings are recoverable only before assessment. It is not a score prediction.
Before you hire anyone: identify the actual gap
The category you need — a C3PAO (CMMC Third-Party Assessment Organization), an RPO (Registered Provider Organization), an MSSP (Managed Security Service Provider), a GRC platform, a network integrator, or a CUI enclave — depends on your required level, FCI versus CUI handling, assessment type, environment, and contract timeline. The written contract requirement sets your path, not a checklist.
Use Find My CMMC Path to map the situation to a provider category before requesting quotes, or read Who To Hire First if you already know the gap. If the architecture is clear but the budget is not, use our CMMC Level 2 cost guide. Do not submit CUI, drawings, credentials, network diagrams, contract numbers, or sensitive system details.
Can you use WPA2 with a shared password for CUI?
Possibly. The official CMMC Level 2 Assessment Guide includes a worked AC.L2-3.1.17 example in which a small company installs a wireless solution that may transmit CUI, selects a product whose encryption is validated against the FIPS 140 standard, and configures WPA2 with a pre-shared key. The guide marks both objectives satisfied. A shared key is therefore not automatically disqualifying under the wireless-protection requirement itself. It also does not automatically satisfy the identity, authorization, password-handling, or offboarding requirements around it. CMMC Assessment Guide – Level 2, pp. 52–53
Let us be precise, because the internet is not.
AC.L2-3.1.17 has exactly two assessment objectives:
- 3.1.17[a] — wireless access to the system is protected using authentication
- 3.1.17[b] — wireless access to the system is protected using encryption
That order matters. Authentication is [a]. Encryption is [b].
Two objectives. That is the whole determination set for this requirement. The guide says open authentication must not be used because it authenticates any user and lacks security capabilities. It then gives two examples: a small company using WPA2-PSK and a larger company using WPA2 Enterprise with RADIUS. The guide says enterprise authentication may be better for larger organizations because it identifies an individual user or device rather than relying on a shared passphrase. “May be better” is not “is required.”
So why does everyone say shared keys fail?
Because a pre-shared key can be hard to defend at scale — not because its mere existence automatically fails five other controls.
| Requirement | What a pre-shared key does not prove by itself |
|---|---|
| IA.L2-3.5.1 | It does not establish the complete identity story for users, processes, and devices. Individual operating-system, directory, VPN, or application identity may provide that evidence. |
| IA.L2-3.5.2 | It does not prove that every covered identity is authenticated at the required access point. A separate account-authentication layer may do that. |
| IA.L2-3.5.10 | It does not answer how the passphrase is stored or transmitted. A PSK is not an automatic failure; plaintext distribution, exposed notes, or uncontrolled messaging create the problem. |
| PS.L2-3.9.2 | It creates an offboarding burden. The official guide itself says the key must be changed when an employee leaves so the former employee cannot reconnect. |
| AC.L2-3.1.1 | It does not prove that system access is limited to authorized users, processes, and devices. It is one credential at one layer, not the complete authorization model. |
Here is the honest framing: the wireless requirement is smaller than everyone tells you. The wireless decision is bigger than everyone tells you.
That distinction matters commercially, too. If a proposal says “802.1X is required for CMMC,” that is not a citation. It is a product recommendation wearing a regulation’s clothes. Ask which CMMC Level 2 requirement mandates 802.1X by name. There is not one.
When a shared key is genuinely defensible
- Very few users and very low turnover
- Every device centrally managed and separately attributable
- The key is not reused on guest or non-CUI networks
- Documented rotation after departure, disclosure, suspected compromise, or scheduled review
- The deployed cryptographic module, version, operational environment, and approved mode match a CMVP validation
- Written wireless authorization records, a current SSID register, and evidence showing who and what may connect
- A separate identity and account-authentication layer that closes what the shared key does not
When it stops being defensible
- Turnover of any real volume
- Shared shop-floor credentials nobody can attribute
- Multiple sites, multiple SSIDs, and no central administration
- Devices that expose or export the key
- A key passed by text, whiteboard, unprotected document, or tribal memory
- Any situation where “who connected?” or “who still knows the key?” has no credible answer
What does each Wi-Fi configuration prove — or fail to prove?
Assessment outcomes depend on the combination of authorization evidence, authentication method, encryption configuration, cryptographic-module validation, CUI flow, asset classification, and the separate account controls around the WLAN. The matrix below is an editorial evidence map built from § 170.24 and the official assessment objectives. It is not a compliance score, certification prediction, or substitute for assessing each applicable objective.
This is the table we built because the binary internet answers are not good enough. Find your row.
| Configuration | AC.L2-3.1.16 | AC.L2-3.1.17 | SC.L2-3.13.11 | Identity and offboarding | Bottom line |
|---|---|---|---|---|---|
| Open / no authentication or encryption | Authorization may still be documented, but the connection mechanism does not enforce it | Fails [a] authentication and [b] encryption | If CUI crosses the link, no encryption means the 5-point condition | Does not solve identity or former-user access | Not viable for a CUI wireless path |
| WPA2-PSK, no validated wireless module, WLAN is the CUI confidentiality layer | Depends on identified access points and prior authorization | Authentication and encryption are present; assess the actual configuration | 3-point condition when encryption is used but is not FIPS validated | Depends on separate user/device identity, key custody, and rotation | The wireless mechanism may work, but the FIPS and evidence files are incomplete |
| WPA2-PSK, matching validated wireless module, WLAN is the CUI confidentiality layer | Depends on authorization records | The official guide’s small-company example can satisfy both objectives | Met only if the exact deployed module, version, operational environment, and approved mode match | Still depends on separate identity and offboarding controls | Potentially defensible in small, controlled environments |
| WPA2/WPA3 Enterprise, password-based EAP | Usually easier to evidence centrally | Can satisfy both objectives when configured correctly | Depends on the exact cryptographic modules and approved mode | Individual attribution improves; password protection and server-certificate validation still require evidence | Enterprise branding does not replace configuration review |
| WPA2/WPA3 Enterprise, EAP-TLS certificates | Usually easier to evidence centrally | Can satisfy both objectives when configured correctly | Still depends on the validated modules — a current certificate is not itself FIPS evidence | Strong individual/device attribution; certificate issuance, revocation, renewal, and trust become the new job | Strong common design, not a named CMMC mandate |
| No CUI on wireless; wired or enclave CUI; isolated guest/corporate WLAN | May be N/A for the assessed wireless path if no in-scope wireless access exists | May be N/A on the same facts | N/A for the wireless path | Separation and asset classification must be proven | Often the cheapest answer when the boundary is real |
Row 2 versus Row 3 is not “the same network with a different purchase order.” It is the same high-level authentication design with a materially different cryptographic-evidence posture. The finding turns on the actual module and deployment, not the letters AES printed in a dashboard.
Rows 4 and 5 expose another trap. “Enterprise” is not a CMMC finding. A password-based EAP design can be secure and assessable, but you still need to validate the server certificate, credential-protection path, module status, and actual configuration. EAP-TLS improves attribution and removes the shared-password problem, but the client and server certificates do not prove that the cryptographic implementation is CMVP validated.
Row 6 is the cheapest answer on this page. If CUI never touches a radio and you can prove it, most of this article stops applying to that path. That is a scoping and architecture decision, not a hardware purchase.
32 CFR § 170.24 says an objective assessed as Not Applicable is equivalent to MET and gives SC.L2-3.13.5 as an example when no publicly accessible systems exist in the assessment scope. N/A is a real documented finding. It is not a loophole. 32 CFR § 170.24(b)(3)
Does your access point itself need FIPS-validated encryption?
SC.L2-3.13.11 requires FIPS-validated cryptography when cryptography is used to protect CUI confidentiality. The official Level 2 guide says FIPS-validated cryptography is required when CUI is transmitted or stored outside the protected environment, including wireless and remote access. Whether that obligation lands on the access point specifically depends on which cryptographic layer is actually protecting the CUI. If wireless encryption is the protection, the wireless module needs the evidence. If CUI is already inside an independently validated end-to-end tunnel or locked-down virtual session, the analysis may move to that layer — provided no local path lets CUI escape it. CMMC Assessment Guide – Level 2, pp. 234–235
This is the question that drives access-point replacement projects, and it is almost always asked backwards. People start with the product. Start with the data.
The five questions, in order
- Does readable CUI actually cross the wireless link?
- If so, is the wireless encryption the mechanism protecting it — or is something else?
- Is CUI already inside a separately validated, end-to-end protected channel when it crosses the air?
- Can the endpoint save, print, copy, cache, screenshot, map a drive, or transfer files outside that channel?
- Does the access point or controller provide a security-protection function for the assessed environment, regardless of whether readable CUI crosses it?
Question 4 is where layered designs die. A virtual desktop that allows only keyboard, video, and mouse is a genuinely different scope story from one that lets users print to a local wireless printer. Same session. Different answer. The rule itself gives a keyboard/video/mouse-only VDI endpoint as an out-of-scope example when it cannot process, store, or transmit CUI beyond that client interaction. 32 CFR § 170.19
Four architecture patterns
| Pattern | Where the FIPS evidence likely lands | What you must be able to demonstrate |
|---|---|---|
| Local CUI over the corporate WLAN | The wireless cryptographic module | CMVP certificate, module/version match, operational environment, approved mode, and deployed firmware relationship |
| CUI inside a validated end-to-end VPN | The VPN cryptographic module may be the confidentiality layer; wireless authorization, authentication, and encryption still apply | The tunnel cannot be bypassed for CUI; no split-tunnel CUI path; no local cache, print, or transfer path that defeats the design |
| Locked-down VDI with no local save, print, clipboard, or transfer | The session-protection module | The restrictions are technically enforced and tested, not merely written in policy |
| Isolated guest WLAN with no CUI and no security role | Potentially nowhere in the CUI scope | Tested routing/firewall separation, no shared management path that provides security to CUI assets, and accurate diagrams/SSP treatment |
This table is an architecture analysis, not a new government rule. There is no single sentence in the official sources that resolves every WLAN, VPN, VDI, printing, endpoint, and enclave combination. Anyone who gives you a universal product answer without tracing the CUI path has skipped the only question that matters.
Map the wireless path before you buy hardware
Answer the five questions above and add the result to your CUI data-flow diagram. Then run the wireless boundary through the 32-point CMMC readiness checklist. If the remaining problem is provider selection rather than architecture, use Find My CMMC Path.
Do not submit CUI, drawings, credentials, IP addresses, network diagrams, contract documents, vulnerabilities, or sensitive security configurations.
Does CMMC require WPA3, 802.1X, RADIUS, EAP-TLS, or MFA on Wi-Fi?
No CMMC Level 2 security requirement names WPA3, 802.1X, RADIUS, EAP-TLS, NAC, or a specific wireless protocol. AC.L2-3.1.17 requires authentication and encryption without prescribing the implementation by name. Multi-factor authentication is separately required by IA.L2-3.5.3 for local and network access to privileged accounts and network access to non-privileged accounts, but no requirement places that MFA at the moment a device joins an SSID.
Three labels, used consistently below, because collapsing them is how bad advice spreads:
- Required by control — the requirement or assessment objective says so
- Named in official guidance — the official guide discusses it as an example or option
- Editorial recommendation — an operational choice based on scale, risk, and evidence burden
| Technology | Status | Our read |
|---|---|---|
| Open authentication | Official guidance says it must not be used | Remove it from any in-scope wireless path |
| WPA2-PSK | Named in official guidance | Potentially workable in small, controlled, low-turnover environments |
| WPA2 Enterprise | Named in official guidance | The guide says it may be better at scale; that is a fit statement, not a mandate |
| WPA3 | Not named in the CMMC requirements | Prefer it where supported and appropriately validated; never call it a CMMC requirement |
| 802.1X | Not named in the CMMC requirements | Common architecture for centralized user/device authentication |
| RADIUS | Named in the guide’s enterprise example | Supporting infrastructure, not a CMMC result by itself |
| EAP-TLS | Not named in the CMMC requirements | Strong common option; certificate lifecycle and module validation become evidence work |
| NAC | Not named in the CMMC requirements | Useful for authorization and posture; can strengthen 3.1.16 evidence |
| WIDS/WIPS | Not named in these requirements | Useful for rogue-access-point visibility; not automatically required by 3.1.16 or 3.1.17 |
On MFA and Wi-Fi specifically
Separate three actions and the confusion evaporates:
- Joining the wireless network. No requirement puts MFA here.
- Accessing a workstation, account, VPN, or application. IA.L2-3.5.3 applies according to whether the access is privileged/non-privileged and local/network.
- Passing through multiple layers. The required access path must enforce MFA; CMMC does not say you must repeat MFA at every technical layer.
IA.L2-3.5.3 is worth noting for a second reason. Along with SC.L2-3.13.11, it is one of only two Level 2 requirements eligible for the rule’s partial-credit treatment. MFA implemented only for remote and privileged users carries a 3-point deduction; no MFA carries 5. 32 CFR § 170.24(c)(2)(i)(B)(4)
Two things not to claim in your SSP: that a device certificate at the Wi-Fi layer automatically satisfies MFA for every covered account, and that WPA2 Enterprise with a password automatically satisfies IA.L2-3.5.3. Neither statement closes the actual account-access objectives.
Which wireless assets are in your CMMC assessment scope?
Scope follows what an asset does, not whether it is wireless. Under 32 CFR § 170.19(c)(1), Level 2 assets fall into five categories: CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets, and Out-of-Scope Assets. An Out-of-Scope Asset cannot process, store, or transmit CUI, cannot provide security protection for a CUI Asset, and must be physically or logically separated from CUI Assets. 32 CFR § 170.19
Now the finding that makes this section worth reading.
The official Level 2 Scoping Guide defines the two kinds of separation this way: physical separation means no wired or wireless connection; logical separation means data transfer between physically connected wired or wireless assets is prevented by non-physical controls such as firewalls, routers, VPNs, or VLANs. CMMC Scoping Guide – Level 2, p. 10
Wireless is named inside the definition of separation. An active wireless connection — or an uncontrolled radio that can auto-connect — can destroy a claimed physical boundary. The mere presence of disabled wireless hardware does not automatically create a connection; the operational state and evidence matter.
That sentence can be more expensive than the access points.
Wireless asset classification
| Asset | Likely treatment | The deciding fact |
|---|---|---|
| Corporate access point carrying CUI traffic | CUI Asset when it actually transmits CUI; document any security-protection role too | Whether CUI crosses it and what capability it provides |
| Wireless controller | Security Protection Asset or CUI Asset, depending on function and data flow | Key custody, management plane, security function, and whether CUI passes through it |
| RADIUS or identity server | Security Protection Asset | It provides authentication/security capability to the assessed environment |
| Guest access point | Potentially Out-of-Scope | Tested isolation, no CUI path, and no security function for a CUI Asset |
| Remote employee’s home router | External system/path requiring architecture analysis; do not assume an asset category | Ownership, endpoint/tunnel design, CUI flow, and what the organization can administer and prove |
| Wireless printer receiving CUI jobs | CUI Asset | Spool files, internal storage, scan paths, and output handling |
| Wireless scanner | CUI Asset when it creates, stores, or sends CUI | Scan destination and local retention |
| Tablet or phone processing CUI | CUI Asset and mobile platform | Whether CUI is processed, stored, or transmitted |
| Wireless CNC, IoT, IIoT, OT, GFE, or test equipment | Often a Specialized Asset; may also require CUI/security treatment | Device type, data handled, function, and isolation |
| Bluetooth peripheral | Architecture-dependent | Whether it creates a path into the assessed system or moves CUI |
| Cellular hotspot | External wireless path | Endpoint scope, tunnel, CUI flow, and authorization |
A caution on the first row. Table 3 to § 170.19 says a CUI Asset is an asset that processes, stores, or transmits CUI. It says a Security Protection Asset provides security functions or capabilities. Do not default every access point to “Security Protection Asset” if it actually transmits CUI. A CUI Asset is assessed against all Level 2 requirements; a Security Protection Asset is assessed against the requirements relevant to the capability it provides. That is not a small documentation difference.
What “logically separated” has to mean in practice
- Firewall and routing rules that have been tested, not just written
- A VLAN or enclave boundary with no unintended management-plane crossover
- No shared credential or identity path that silently creates a route
- No shared printers, file shares, or internal services reachable from the isolated side
- No uncontrolled printing, clipboard, local storage, drive mapping, or file transfer across the boundary
- A network diagram, asset inventory, data-flow diagram, and SSP that match what is actually running
For the broader control map, use the NIST SP 800-171 requirements checklist. If the unresolved issue is who should perform scoping versus implementation, use the CMMC provider categories guide.
Are guest, home, public, and cellular connections in scope?
None of these receives an automatic classification based on who owns the equipment or where it sits. The answer turns on the CUI flow, asset function, security-protection role, contractual scope, and whether separation or end-to-end protection can be demonstrated. Blanket claims in either direction — “home Wi-Fi is always out of scope” or “home Wi-Fi is always in scope” — are unsupported.
Guest Wi-Fi
Guest networks are usually fine. They are usually fine because of the configuration, not because of the label.
Checklist for a defensible guest network:
- Dedicated SSID on a dedicated VLAN or equivalent boundary
- Internet-only routing, verified
- No route to CUI systems, tested and recorded
- Separate administrative credentials and management controls where architecture requires them
- No shared printers or internal services
- Periodic revalidation after network changes
- Asset inventory, diagram, and SSP treatment that match the test result
Do not automatically label SC.L2-3.13.5 the “guest Wi-Fi control.” That requirement covers publicly accessible system components. It can matter when such components exist, but a guest SSID is not automatically a publicly accessible system component. The broader guest-network analysis usually rests on scope, boundary protection, network communications, and external connections. Section 170.24 uses SC.L2-3.13.5 only as its example of a legitimate N/A finding when no publicly accessible systems exist.
Home and public Wi-Fi
Here is a detail that changes the risk calculus. Section 170.21(a)(2)(iii) names six specific requirements that may never appear on a CMMC POA&M regardless of point value. One is AC.L2-3.1.20, which requires verification and control of connections to and use of external systems. It is worth one point and the rule specifically makes it non-deferrable.
Our editorial reading: an employee’s home router or public network is a strong candidate for the external-system analysis, but the exact asset treatment is architecture-dependent. Confirm applicability before building a plan around it.
The questions that resolve remote work:
- Is the endpoint in scope?
- Does readable CUI ever reach the local network?
- Is split tunneling enabled, and can CUI use it?
- Can the user print, save, cache, screenshot, or transfer locally?
- Where exactly does the validated tunnel or VDI session begin and end?
- Which components provide security protection to the CUI environment?
- What can the contractor administer, monitor, test, and prove?
Cellular hotspots
Cellular is another wireless path, not a loophole. Evaluate the endpoint, authorization, tunnel, CUI flow, and evidence. The carrier’s encryption does not replace the contractor’s responsibility to prove the required protections on the assessed path.
What do printers, tablets, IoT, OT, and Bluetooth change?
These technologies matter because they create wireless paths that often go undocumented. Under 32 CFR § 170.4, Specialized Assets include Government Furnished Equipment, Internet of Things and Industrial Internet of Things devices, Operational Technology, Restricted Information Systems, and test equipment. A device’s marketing label does not determine its assessment treatment. Its asset category, function, data, connectivity, and documented isolation do. 32 CFR § 170.4
Wireless printers
Trace the entire path: client → wireless → print server → printer → spool file → printer storage → management interface → output tray → scan-to-email.
A wireless printer is a common way a carefully designed virtual-desktop boundary springs a leak. Everything is locked down except printing because printing felt like an exception. It is not one. If CUI leaves the protected session to reach a printer over Wi-Fi, the local endpoint and wireless path need to be re-evaluated.
Phones and tablets
AC.L2-3.1.18 (control mobile-device connections, 5 points) applies when mobile devices connect to the assessed system. AC.L2-3.1.19 (encrypt CUI on mobile devices, 3 points) applies when CUI resides on mobile devices or mobile computing platforms. Cover authorization, MDM enrollment where used, device encryption, local caching, lost-device response, screen capture, backup destinations, and personal versus corporate ownership.
IoT, IIoT, OT, GFE, and test equipment
Distinguish four situations that get mashed together:
- A general-purpose asset that processes, stores, or transmits CUI — a CUI Asset
- An IoT, IIoT, OT, GFE, Restricted Information System, or test device — potentially a Specialized Asset even when it can handle CUI; document its treatment under the rule
- An asset providing a security capability to the CUI environment — a Security Protection Asset
- An asset that cannot process, store, or transmit CUI, provides no security function, and is separated — potentially Out-of-Scope
CM.L2-3.4.6 and CM.L2-3.4.7 cover least functionality and restriction of nonessential functions, ports, protocols, software, and services. Both are worth 5 points and are non-deferrable. A shop-floor machine with an enabled Wi-Fi or Bluetooth function nobody uses, inventories, restricts, or disables is exactly the kind of unexamined functionality those requirements force you to confront.
Bluetooth
AC.L2-3.1.16 and AC.L2-3.1.17 say “wireless.” They do not say “Wi-Fi.” Our editorial reading is that a Bluetooth connection creating a path into an assessed system, or moving CUI, deserves the same authorization and protection analysis. A low-risk peripheral may be easy to document. Bluetooth file transfer into a machine controller is not the same problem.
What if your access points are not FIPS validated?
Do not start with a purchase order. Start by determining whether the access point’s cryptography is the layer protecting CUI, whether another validated layer covers the full path, and whether printing, caching, split tunneling, or local transfer defeats that design. A validated algorithm alone is not enough. The specific cryptographic module, product-to-module relationship, version or release, operational environment, and approved mode must match the CMVP record and security policy. NIST CMVP FAQ
Now the damaging admission, and we would rather say it than have you find out later: for many small and mid-size defense contractors, the wireless portion of CMMC is configuration work, a certificate lookup, testing, and paperwork — not a purchase. We are an independent trade publication that may make money routing readers to providers, and we are telling you that some of you do not need to hire anyone to close these two controls.
Here is why we will say that out loud. The configuration is often the cheap part. The evidence is what fails — the SSID register that does not exist, the authorization record nobody kept, the certificate that covers a different module or version than the one running, the firmware change nobody rechecked. That is where outside help earns its fee. If you can produce and defend the evidence yourself, keep your money.
Seven-step triage
- Inventory. Every access point, controller, firmware version, SSID, authentication mode, and encryption mode.
- Map. Every CUI path that uses wireless.
- Identify the protecting layer. Wireless, VPN, VDI, application, or another mechanism.
- Search CMVP by module, not by the product’s marketing name.
- Match the evidence. Module, certificate number, version/release, operational environment, approved mode, and product relationship.
- Test the leaks. Local print, file transfer, cache, clipboard, split tunnel, scan-to-email, fallback SSID, and administrative path.
- Decide. Configuration change, tunnel, segmentation, enclave, or replacement — in that order of cost.
What to demand from your vendor
Do not accept “FIPS capable,” “FIPS compliant,” “AES-256,” or “FIPS inside” as the whole answer. Ask for:
- The cryptographic module name and CMVP certificate number
- The exact product-to-module relationship
- The version, release, or firmware the certificate covers
- The validated operational environment
- The security policy and approved-mode instructions
- Written configuration steps to enter and remain in approved mode
- A signed mapping letter when the product embeds another vendor’s validated module
NIST says an embedded validated module does not make the entire product validated, and it recommends checking the vendor’s signed mapping against the CMVP entry. If the vendor cannot produce that chain, you have learned something useful about the vendor. NIST CMVP FAQ
Build the evidence file before you replace the network
The evidence list and rehearsal below are the records most contractors discover too late: access-point inventory, SSID register, wireless authorization records, shared-key custody and rotation, mobile-device authorization, CMVP tracker, CUI data-flow worksheet, guest-isolation test, configuration exports, and an SSP wireless section.
What changes for FIPS 140-2 wireless products after September 21, 2026?
NIST’s Cryptographic Module Validation Program says FIPS 140-2 modules can be accepted for new systems through September 21, 2026. On September 22, the remaining FIPS 140-2 validation certificates move to the Historical list, and only FIPS 140-3 validations remain active. NIST also says Historical is not the same as Revoked and allows agencies to continue using those FIPS 140-2 modules for existing systems. NIST CMVP transition page · NIST CMVP FAQ
This date is real, it is close, and vendors are using it to sell hardware refreshes right now. So here is the part the sales page may not tell you.
September 22 is not an automatic CMMC failure date for every existing FIPS 140-2 deployment. Historical status is not revocation. NIST describes it as a certificate that is older or moved because of a program transition; a revoked module, by contrast, may no longer be referenced to demonstrate FIPS validation.
It is also not a blank check. NIST’s existing-system language is not a universal CMMC safe harbor for every contractor architecture. You still need the exact certificate, deployment match, approved mode, vendor support, and a defensible explanation of whether the product was part of an existing system. If the decision controls contract eligibility or a major purchase, confirm the treatment with the responsible assessor, practitioner, or contracting authority.
The current CMMC Level 2 Assessment Guide’s explanatory text still defines FIPS-validated cryptography by reference to FIPS 140-2. NIST now validates new modules under FIPS 140-3, and after September 21, 2026, an active FIPS 140-3 validation is the cleanest evidence posture for a new system. The CMMC requirement itself is to use FIPS-validated cryptography when cryptography protects CUI confidentiality; it does not prohibit the newer FIPS 140-3 standard.
Editorial recommendation, stated as such: if you are selecting wireless equipment in the second half of 2026, prioritize an active FIPS 140-3 validation over a 140-2 dependency that becomes historical within weeks of installation. If you already operate properly configured, documented 140-2 equipment, capture the certificate status, module/version relationship, operational environment, approved mode, original deployment context, vendor support status, risk decision, and upgrade path — then move on to a problem that is actually costing you points.
For the full transition mechanics, see our CMMC FIPS 140-2 requirements guide.
What will an assessor actually inspect, ask, and test?
NIST SP 800-171A June 2018, incorporated into the CMMC rule, uses three assessment methods: examine, interview, and test. For AC.L2-3.1.17, the official guide lists policies, design documentation, wireless procedures, the SSP, configuration settings, and audit records as potential examine objects; administrators and security personnel as interview subjects; and the mechanisms implementing wireless protection as test objects. NIST SP 800-171A · CMMC Assessment Guide – Level 2, p. 52
One line from § 170.24 governs all of it: evidence must be in final form, not draft. Working papers, drafts, and unofficial or unapproved policies are unacceptable evidence.
Your draft wireless policy is not acceptable assessment evidence.
Documents to have ready
| Evidence | What it supports |
|---|---|
| Approved wireless policy and usage restrictions | AC.L2-3.1.16 / AC.L2-3.1.17 |
| Access-point, controller, firmware, and SSID inventory | AC.L2-3.1.16[a], CM.L2-3.4.1 |
| SSID register with owner, purpose, CUI status, authentication, encryption, and boundary | AC.L2-3.1.16 / scoping |
| Wireless authorization records — who approved which access point/device and when | AC.L2-3.1.16[b] |
| Authentication and encryption configuration exports | AC.L2-3.1.17[a][b] |
| Shared-key or certificate lifecycle procedure and records | AC.L2-3.1.17; operational support for offboarding and access control |
| CMVP certificate register with module, version/release, operational environment, and approved mode | SC.L2-3.13.11 |
| Mobile-device authorization, encryption, and MDM records where used | AC.L2-3.1.18 / AC.L2-3.1.19 |
| CUI data-flow diagram showing every wireless or remote path | SC.L2-3.13.8 / scoping |
| Guest-network and segmentation test record | Boundary and out-of-scope evidence |
| Connection and administrative records used by the organization | Potential evidence for AC.L2-3.1.16 and applicable AU requirements |
| Exception register for legacy devices, specialized assets, and fallback SSIDs | SSP, asset treatment, and applicable requirements |
Nine questions your administrator should be ready to answer
- Who approves a new access point, SSID, device, or wireless exception?
- How are wireless access points identified and kept current?
- Who can issue credentials or disclose a pre-shared key?
- What happens to wireless access when someone leaves or a device is lost?
- How do you identify unauthorized or rogue wireless equipment?
- How are mobile devices approved before they connect or handle CUI?
- How do you re-check the CMVP match after a firmware, controller, or operating-environment change?
- How are printers, IoT, OT, Bluetooth, and legacy-device exceptions handled?
- How do the SSP, asset inventory, authorization records, and network diagram get updated after a change?
The eleven-step live rehearsal
Run this yourself before anyone else runs it on you.
- Show the authoritative access-point and SSID inventory.
- Tie one access point and one SSID to their written authorization.
- Show the live authentication and encryption settings.
- Connect an approved device.
- Demonstrate how an unauthorized device or user is rejected or denied access.
- Show offboarding or key/certificate-revocation evidence from a real personnel or device event.
- Show the connection or administrative records your policy says you retain.
- Demonstrate guest or non-CUI network isolation with a recorded test.
- Show the CMVP certificate and prove the deployed module, version, operational environment, and mode match.
- Trace the implementation back to the SSP, asset inventory, and network/data-flow diagrams.
- Where the boundary depends on it, demonstrate that local print, save, transfer, clipboard, drive mapping, cache, screenshot, and split-tunnel paths are blocked as claimed.
Language to keep out of your SSP
“All wireless is CMMC compliant.” “AES-256 is FIPS.” “Our vendor is FIPS certified.” “Home Wi-Fi is out of scope.” “VPN makes everything compliant.” “WPA3 satisfies the wireless controls.”
Every one of those is a sentence someone can ask you to prove, and none can be proved as written. Write only what you can demonstrate.
For Level 2 (Self), an affirming official submits the required affirmation under § 170.22, and the organization must retain assessment artifacts for six years. The Phase 2 suspension removes the mandatory C3PAO checkpoint from new Phase 2 designations during the pause; it does not remove government-led assessment authority. Section 170.16 expressly reserves DoD’s right to conduct a DCMA DIBCAC assessment, and those results can supersede a pre-existing self-assessed CMMC status. 32 CFR § 170.16 · 32 CFR § 170.22
What changes at CMMC Level 1 and CMMC Level 3?
CMMC Level 1 contains no wireless-named requirement. Under § 170.14(c)(2), Level 1 uses the 15 basic safeguards in FAR 52.204-21(b)(1), none of which names wireless. CMMC Level 3 also contains no requirement with “wireless” in its text — but five of the 24 selected February 2021 NIST SP 800-172 requirements can be materially affected by wireless architecture. 32 CFR § 170.14 For the broader differences, see our CMMC Levels guide.
Level 1
No wireless-specific control. The general Level 1 safeguards still apply to the covered contractor information system. If you handle FCI but not CUI, start with the CMMC Level 1 self-assessment checklist and confirm the actual solicitation or flow-down.
Level 3
We read all 24 rows in Table 1 to § 170.14(c)(4). The word “wireless” does not appear. The following five are the clearest wireless-architecture intersections. The “what it means” column is editorial interpretation, not additional rule text.
| Level 3 requirement | Rule text, condensed | What it can mean for wireless |
|---|---|---|
| IA.L3-3.5.1e | Bidirectionally authenticate systems/components with cryptography that is replay resistant, where possible, before network connection | Points toward mutual certificate-based authentication or an equivalent design; no EAP method is mandated by name |
| IA.L3-3.5.3e | Prohibit components from connecting unless known, authenticated, properly configured, or in a trust profile | Device identity and posture enforcement before wireless access |
| AC.L3-3.1.2e | Restrict access to information resources owned, provisioned, or issued by the organization | Strongly constrains unmanaged BYOD and can rule it out for the Level 3 environment unless the resource fits the requirement |
| SC.L3-3.13.4e | Employ physical isolation, logical isolation, or both | Makes the SSID/VLAN/enclave boundary explicit |
| SI.L3-3.14.3e | Include specialized assets in enhanced scope or segregate them in purpose-specific networks | The shop-floor IoT/IIoT/OT wireless decision |
NIST published SP 800-172 Revision 3 in May 2026 and lists the February 2021 publication as superseded. That does not change CMMC Level 3 by itself. Section 170.14 still incorporates the selected February 2021 requirements. The same rule applies at Level 2: NIST SP 800-171 Revision 3 is newer in NIST’s catalog, but Revision 2 remains the CMMC-controlling version until DoD amends the rule. NIST SP 800-172 Revision 3 · Rev. 2 vs. Rev. 3 comparison
One more Level 3 note with real consequences: § 170.24(c)(3) requires a maximum score on the Level 2 certification assessment before a Level 3 certification assessment can begin. Maximum means 110 of 110. A Level 3 candidate cannot carry an unmet Level 2 wireless requirement into the Level 3 assessment.
Does the CMMC Phase 2 suspension change any of this?
No. The July 13, 2026 suspension paused the transition to mandatory Phase 2 procurement designations and all later milestones. During the pause, new designations are limited to Level 1 (Self) and Level 2 (Self), and select government-led assessments may continue. The wireless requirements in NIST SP 800-171 Revision 2 did not change. DFARS 252.204-7012 safeguarding obligations did not change. CMMC Level 2 self-assessment results and annual affirmations still go to SPRS when Level 2 (Self) is contractually required.
What was suspended: the scheduled November 10, 2026 move into Phase 2, new Level 2 (C3PAO) and Level 3 (DIBCAC) procurement designations during the pause, and the later rollout milestones.
What remains: the requirements that determine the Level 2 score, the organization’s self-assessment duty where required, annual affirmation, artifact retention, contract remedies, and government assessment authority.
Why the regulation and the current implementation can look inconsistent. The four-phase schedule is still printed in 32 CFR Part 170. The July 13 procedures suspended implementation of the later phases without rewriting the CFR schedule. Read the live solicitation, amendments, contract modifications, and flow-downs — not only the old calendar and not only a headline.
A 2026 clause-number trap
The clause landscape now has two layers:
- The codified DFARS still displays 252.204-7019 and 252.204-7020.
- Effective February 1, 2026, under DoW Class Deviation 2026-O0025 for covered solicitations and contracts, 252.204-7019 is not prescribed and the government-assessment clause appears as 252.240-7997 in place of 252.204-7020.
- 252.204-7012 and the CMMC clause 252.204-7021 remain unchanged by that renumbering.
- Existing contracts and flow-downs can still contain the legacy clause numbers. The actual instrument controls.
Do not use “SPRS score” as one undifferentiated phrase. A legacy NIST SP 800-171 Basic Assessment score under 7019/7020 and a CMMC Level 2 (Self) result under 32 CFR § 170.16/DFARS 252.204-7021 are related but not identical records. The minimum CMMC Level 2 self-assessment entry listed in § 170.16 includes the level, status date, assessment scope, associated CAGE codes, overall score, and POA&M status; the affirmation follows § 170.22. Current DFARS Part 252 · DoW FAR/DFARS class deviations · DFARS 252.204-7021
The wireless angle nobody should miss. During the suspension, a contractor pursuing Level 2 (Self) does not pass through a mandatory C3PAO assessment before relying on its self-assessed status. That makes the evidence burden more—not less—important. An affirming official submits the required affirmation, and DoD retains the right to conduct a DIBCAC assessment that can supersede the self-assessed result.
The suspension did not make wireless less important. It removed one expected external checkpoint from the current procurement rollout while leaving the score, evidence, and enforcement mechanisms behind it.
Two calendar facts matter now: the Department’s July 13 procedures announced a 60-day review, and FIPS 140-2 certificates move to the Historical list after September 21, 2026. Re-check both before a material assessment or purchase decision.
Which provider category should handle a wireless gap?
The right category depends on whether the unresolved problem is scope, technical implementation, evidence management, contract interpretation, or formal assessment. Readiness and formal assessment must remain separated. Section 170.8 requires the Cyber AB’s Code of Professional Conduct to prohibit a CMMC Ecosystem member from participating in a Level 2 certification assessment when that member served as a consultant preparing the organization for a CMMC assessment within the prior three years. C3PAOs also must comply with the conflict-of-interest policies required by §§ 170.8 and 170.9. 32 CFR § 170.8 · 32 CFR § 170.9
| Your actual gap | Category that fits |
|---|---|
| Not sure whether the access point, endpoint, home network, printer, controller, or tunnel is in scope | RP/RPO or a qualified CMMC scoping advisor |
| Need your solicitation, clause, or flow-down legally interpreted | Qualified federal-contracts attorney; ask the contracting officer or prime for written clarification |
| Need WLAN authentication, VLANs, RADIUS, certificates, logging, or validated mode configured | CMMC-focused MSP/MSSP or qualified network integrator |
| Need to keep CUI off ordinary Wi-Fi and ordinary endpoints | CUI enclave, locked-down VDI, or secure collaboration implementer |
| Need the SSP, asset inventory, data-flow diagrams, CMVP register, and evidence process built | RP/RPO plus a GRC platform where useful |
| Ready for a formal Level 2 certification assessment when an applicable path requires it | Cyber AB-authorized or accredited C3PAO, independently selected and conflict-checked |
A boundary worth stating plainly. A C3PAO is the formal Level 2 certification-assessment category, not the default implementation partner. The exact rule is not “no company may ever offer both kinds of service.” The rule is that a CMMC Ecosystem member who consulted to prepare the organization cannot participate in that organization’s Level 2 certification assessment within three years, and the C3PAO must manage actual and perceived conflicts. Ask for the conflict analysis in writing.
And a second boundary. A GRC platform organizes evidence. It does not configure access points, validate cryptographic modules, or satisfy CMMC on its own. Any vendor implying otherwise is describing a workflow tool as if it were a security control.
The CMMC Path Framework maps your required level, FCI/CUI handling, assessment type, environment, and timeline to a provider category. It routes to a category, not a certification prediction, score, or government-endorsed provider.
Identify the category before you take a sales call
Tell the tool your required level, CUI scope, wireless environment, and timeline. It maps your situation to the provider category most likely to fit so you request the right quotes instead of five wrong ones.
Do not submit CUI, drawings, credentials, network diagrams, contract files, export-controlled technical data, vulnerabilities, or sensitive security details.
Already know the category and need competing proposals? Use the separate request-a-quote form, which discloses how provider routing and compensation work.
What we actually verified for this guide
Verified August 21, 2026
- 32 CFR §§ 170.14, 170.16, 170.19, 170.21, 170.22, and 170.24. Level 2 remains identical to NIST SP 800-171 Revision 2; the minimum SPRS fields, asset categories, POA&M rules, evidence rules, point values, partial-credit conditions, and DIBCAC investigation authority were checked against current eCFR text.
- CMMC Assessment Guide – Level 2, Version 2.13 (September 2024). Confirmed AC.L2-3.1.17[a] is authentication,
[b]is encryption; the WPA2-PSK and RADIUS examples; the open-authentication warning; the FIPS module requirement; and the examine/interview/test objects.- CMMC Scoping Guide – Level 2. Confirmed that logical separation addresses physically connected wired or wireless assets and that physical separation means no wired or wireless connection.
- NIST SP 800-171 Revision 2 and NIST SP 800-171A June 2018. Confirmed the controlling Level 2 baseline and assessment methods.
- NIST SP 800-172 February 2021 and 32 CFR § 170.14(c)(4). Read all 24 selected Level 3 rows. NIST’s May 2026 Revision 3 does not change the incorporated CMMC baseline without a DoD rule change.
- NIST CMVP transition and FAQ pages. Confirmed the September 21, 2026 FIPS 140-2 active-list date, existing-systems language, Historical-versus-Revoked distinction, embedded-module limitation, and module/version/operational-environment verification steps.
- July 13, 2026 CMMC suspension procedures. Confirmed Phase 2 and later milestones are suspended, new designations are limited to Level 1 (Self) and Level 2 (Self), select government-led assessments remain possible, and DFARS 252.204-7012 remains in effect.
- DFARS clause state. Checked current codified 252.204-7012, -7019, -7020, and -7021, plus the in-force class-deviation crosswalk for covered solicitations and contracts. The article tells readers to rely on the actual contract because legacy and deviation numbers can coexist.
- Cyber AB CAP, independence, and Marketplace role. Confirmed the CMMC Assessment Process (CAP) v2.0 is procedural guidance for Level 2 certification assessments; it does not define the Level 2 requirement set or scoring. Used 32 CFR §§ 170.8–170.9 for the three-year consultant-participation prohibition and C3PAO duties. Any named C3PAO should be checked in the live Cyber AB Marketplace before engagement.
What we did not verify, and neither should you take on faith: any specific access point, controller, VPN, VDI, firmware, operating environment, or vendor FIPS claim. Product evidence depends on the exact module, version, deployment, CUI flow, and assessment boundary. We did not independently test equipment.
What is editorial judgment, labeled as such: which architecture pattern fits a contractor; how a pre-shared key affects evidence burden outside AC.L2-3.1.17; whether a home router is treated as part of a particular external-system analysis; how Bluetooth should be handled in a specific environment; and which provider category to engage first. Those are applications of verified requirements, not additional government requirements.
Our source-selection and correction standards are public: Methodology · Editorial Standards · Editorial Review Process · Corrections Policy.
Frequently asked questions
Is Wi-Fi allowed under CMMC Level 2? Yes. Wireless access must be authorized before connection under AC.L2-3.1.16 and protected with authentication and encryption under AC.L2-3.1.17. Nothing in 32 CFR Part 170 or NIST SP 800-171 Revision 2 bans wireless.
Does CMMC require WPA3? No. No CMMC Level 2 requirement names WPA3. Use it where the hardware, clients, cryptographic validation, and operational needs support it, but do not describe it as a CMMC requirement in the SSP.
Can WPA2 with a pre-shared key meet AC.L2-3.1.17? Potentially. The official Level 2 Assessment Guide includes a small-company example using a FIPS 140-validated wireless solution configured with WPA2 and a pre-shared key on a network that may transmit CUI, and marks [a] authentication and [b] encryption satisfied. Whether the surrounding identity, authorization, password-handling, and offboarding evidence holds up is a separate question.
Is WPA2 Enterprise required? No. The guide says it may be better for larger organizations because it authenticates an individual user or device rather than relying on a shared passphrase. That is an implementation-fit statement, not a mandate.
Is 802.1X required for CMMC? No requirement names 802.1X. It is a common implementation for centralized identity and device authentication, which is different from being required by name.
Is EAP-TLS required? No. It is a strong certificate-based option. If you deploy it, certificate issuance, renewal, revocation, trust, configuration, and the underlying cryptographic-module evidence become part of the operating burden.
Does connecting to Wi-Fi require multi-factor authentication? No requirement places MFA at SSID association. IA.L2-3.5.3 requires MFA for local and network access to privileged accounts and network access to non-privileged accounts. Show where the covered access path enforces it.
Does my access point itself have to be FIPS validated? Its cryptographic module needs matching FIPS evidence when that module is the layer protecting CUI confidentiality. In an independently validated end-to-end tunnel or locked-down VDI architecture, the evidence obligation may move to that layer, but the full path and every local escape route must be demonstrated.
Is guest Wi-Fi out of scope? It can be when it cannot process, store, or transmit CUI, provides no security function to a CUI Asset, and is genuinely separated. A different network name is not evidence. A tested boundary and accurate asset treatment are.
Is an employee’s home router in scope? There is no safe universal answer. Ownership, endpoint scope, CUI flow, tunnel design, local capabilities, and what the organization can administer and prove determine the treatment. AC.L2-3.1.20 is also one of the six requirements the rule expressly forbids on a POA&M.
Do wireless printers expand CMMC scope? They can. A printer that receives, spools, stores, scans, or outputs CUI can be a CUI Asset, and printing can create a local CUI path that defeats an otherwise tight VDI or enclave boundary.
Do Bluetooth and cellular count as wireless? AC.L2-3.1.16 and AC.L2-3.1.17 say “wireless,” not “Wi-Fi.” Our editorial reading is that a wireless connection into an assessed system, or a wireless path that moves CUI, deserves the same authorization, protection, scope, and evidence analysis.
Can a wireless failure go on a POA&M? The two wireless-named requirements cannot because each is worth 5 points. The narrow exception is SC.L2-3.13.11 when encryption is employed but is not FIPS validated, which carries a 3-point deduction and may be placed on a CMMC POA&M. AC.L2-3.1.20 is worth 1 point but is separately prohibited from a POA&M.
Did the July 2026 Phase 2 suspension eliminate wireless requirements? No. It suspended the Phase 2 transition and later rollout milestones. NIST SP 800-171 Revision 2, Level 2 (Self) mechanics where contractually required, annual affirmations, DFARS 252.204-7012, and government assessment authority remain.
Does NIST SP 800-171 Revision 3 change the wireless controls? Not under the current CMMC rule. Section 170.14 says Level 2 is identical to NIST SP 800-171 Revision 2. Revision 3 is newer in NIST’s catalog, but it does not become the CMMC assessment baseline unless DoD amends the rule or applicable contract framework.
Does NIST SP 800-172 Revision 3 change CMMC Level 3? Not automatically. The current rule incorporates 24 selected requirements from the February 2021 publication. NIST’s May 2026 Revision 3 does not replace that incorporated CMMC baseline without a rule change.
Need help deciding what type of CMMC provider you need?
Tell us your written requirement, non-sensitive scope, environment, and timeline, and we will map the situation to the provider category that fits.
Already know the category and need multiple proposals?
Do not submit CUI, drawings, credentials, network diagrams, export-controlled technical data, contract files, vulnerabilities, incident details, or other sensitive security information.
Disclosure: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or verification of Cyber AB status. See our Editorial & Advertising Policy.
Not advice: This article is educational research. It is not legal, contractual, procurement, cybersecurity, or compliance advice. Confirm scope and implementation with a qualified CMMC practitioner, and use a qualified federal-contracts attorney or contracting authority for clause interpretation. The written contract requirement and the actual CUI environment control — not a checklist and not this page.
Corrections: Found an error? We publish corrections. Contact the editorial team through our corrections process.
Primary sources
- 32 CFR Part 170 — CMMC Program Rule
- 32 CFR § 170.8 — Accreditation Body and Code of Professional Conduct requirements
- 32 CFR § 170.9 — C3PAO requirements
- 32 CFR § 170.14 — CMMC Model
- 32 CFR § 170.16 — Level 2 self-assessment and SPRS requirements
- 32 CFR § 170.19 — CMMC scoping
- 32 CFR § 170.21 — CMMC POA&M requirements
- 32 CFR § 170.22 — Affirmation requirements
- 32 CFR § 170.24 — CMMC Scoring Methodology
- FAR 52.204-21 — Basic Safeguarding of Covered Contractor Information Systems
- DFARS 252.204-7012 — Safeguarding Covered Defense Information and Cyber Incident Reporting
- DFARS 252.204-7019 — Notice of NIST SP 800-171 DoD Assessment Requirements, codified text
- DFARS 252.204-7020 — NIST SP 800-171 DoD Assessment Requirements, codified text
- DFARS 252.204-7021 — CMMC Level Requirements
- DoW Class Deviation 2026-O0025 materials — FAR Part 40 / DFARS Part 240
- NIST SP 800-171 Revision 2
- NIST SP 800-171A June 2018
- NIST SP 800-172 February 2021
- NIST SP 800-172 Revision 3, May 2026
- CMMC Assessment Guide – Level 2, Version 2.13
- CMMC Scoping Guide – Level 2
- Cyber AB CMMC Assessment Process (CAP) v2.0
- Cyber AB Marketplace
- NIST Cryptographic Module Validation Program
- NIST CMVP FAQ
- Department of War memorandum 26-P-1023 — Implementing the Suspension of CMMC Phase II