AC.L2-3.1.17 Wireless access protection requirements

What AC.L2-3.1.17 wireless access protection requires in CMMC Level 2

If your Wi-Fi network can reach a system that holds CUI, AC.L2-3.1.17 applies to it, and it asks for two things at once: wireless access must be protected with authentication and with encryption. The assessment guidance for NIST SP 800-171A breaks this into two objectives, one for protecting wireless access to the system with authentication and one for protecting it with encryption. An assessor will test each objective separately, so a network that encrypts traffic but lets any device join without identifying itself does not meet the requirement, and neither does a network that authenticates users over an unencrypted link. Requirement AC.L2-3.1.17 is worth 5 points under the CMMC Scoring Methodology, so if it is scored NOT MET, 5 points come off the maximum score of 110. Because it is worth more than 1 point, it cannot be placed on a plan of action and milestones (POA&M), so it must be MET before you can reach Conditional or Final Level 2 status.

The most common failure is a WPA2-PSK network, where every device shares one passphrase. The CMMC Assessment Guide for Level 2 contrasts this with WPA2 Enterprise, which authenticates each user or device individually, typically against a RADIUS server, and says open authentication must not be used. A shared passphrase cannot show who or what connected, and it must change whenever someone who knew it leaves, which in practice rarely happens on schedule. Before you deploy anything, confirm with your access point vendor which WPA modes and authentication methods each model supports, and confirm with your assessor that the encryption you choose meets the FIPS-validated cryptography expected by SC.L2-3.13.11.

Start by inventorying every wireless network that touches the CUI boundary, including guest networks that share hardware with corporate ones, and record the authentication mode and cipher configuration for each. Assessors commonly ask for wireless implementation and usage procedures, configuration settings and audit records, and they may test the mechanisms directly by attempting to join with an unauthorized device. Keep the exported configuration, the RADIUS or identity source settings and a sample of connection logs in final form, since drafts do not count toward a MET determination. Where a RADIUS server or certificate authority is involved, document who owns it, how certificates are issued and revoked, and how the server is protected. Open-source options such as FreeIPA, which includes a Dogtag-based certificate authority, can support certificate issuance, but whether a given access point or RADIUS product supports your chosen method is a question to confirm in your own environment.

Which wireless networks, devices and teams fall under AC.L2-3.1.17

Wireless scope is decided before any configuration is checked. The questions below determine which access points, controllers, SSIDs, devices and administrators an assessor will test against AC.L2-3.1.17 Wireless access protection, and they should be answered in writing in the system security plan.

Guest and corporate SSIDs

Every SSID that can reach a system holding CUI, or a network path to one, sits inside the assessment boundary. A guest network that is isolated from CUI systems by enforced segmentation is a different case from a corporate SSID that bridges to a file share. Document each SSID, its authentication method and whether traffic from it can reach CUI assets. Confirm the isolation with a firewall rule review rather than with the network diagram alone.

Access points and controllers in scope

Access points, wireless controllers, cloud management consoles and the RADIUS or identity servers they depend on can all affect how wireless access is protected. Assessors look at the components that enforce authentication and encryption, so the inventory should list each one, its location and its management interface. Ask your wireless vendor or integrator to confirm which management functions run on-premises and which run in a hosted service, because a hosted service may fall outside your direct control.

Personally owned devices on Wi-Fi

Personal phones and laptops that join a corporate SSID create an external connection risk that AC.L2-3.1.20 also addresses. Decide whether personal devices may use any SSID that reaches CUI, and if they may, record how each device is identified and authorized before it connects. If they may not, the network should block them through separate SSIDs or certificate-based onboarding that excludes unmanaged devices.

Wireless administrators and administrative access

The people and accounts that can change SSID settings, authentication servers or controller policies belong in scope, as do the tools they use. Document who administers the wireless infrastructure, how those administrators authenticate, and whether privileged changes are logged. Review the access list each time staff change roles or leave.

Third-party managed wireless

When a managed service provider or cloud vendor operates the wireless network, the contract, the administrator accounts and the evidence that the provider follows your configuration all matter. Confirm in writing what the provider controls, what you control, and what evidence the provider will supply to your assessor. The organization remains responsible for its controls even when a third party runs them, so the provider's configuration exports and change records should be retained with your own evidence.

Wireless in scope for the assessment

Some of the decisions above can be answered only after the CUI data flow is mapped. Start from the systems that store, process or transmit CUI, then trace every wireless path into them. Any access point, SSID or controller on that path belongs in the assessment boundary, and any path you intend to exclude should be justified and tested. Treat the boundary as a documented decision that is reviewed whenever Wi-Fi is added or changed.

How an assessor tests wireless access protection

This table compares how an assessor tests the two NIST SP 800-171A objectives behind AC.L2-3.1.17: authentication of wireless access and encryption of it. Read each row as a test step, with the evidence requested, what the assessor checks on the controller or access point, and the findings that most often cause a NOT MET result.

Test element	Objective 1: Authentication	Objective 2: Encryption
Evidence requested	Wireless implementation and usage procedures, the authentication method for each SSID, and records of who or what holds credentials	Wireless configuration settings showing the cipher suite and protocol version for each SSID, plus the procedure for approving changes to them
Configuration evidence	Authentication mode per SSID, RADIUS or directory integration settings, and whether any SSID accepts open authentication	Encryption setting per SSID, enabled protocol versions, and whether any guest or legacy network carries CUI-facing traffic without encryption
Audit records	Logs showing successful and failed device or user authentications to the wireless network, with time stamps	Records of configuration changes to cipher or protocol settings and of who approved them
What the tester checks on the controller	Confirms that each SSID authenticates individual users or devices, not a shared secret, and that the authentication server is the one documented	Confirms that encryption is enabled on every SSID that reaches the system, and that the cryptography is the FIPS-validated standard referenced by SC.L2-3.13.11
What the tester checks on the access point	Samples access points to confirm they inherit the controller's authentication settings and have no local override	Samples access points to confirm they do not fall back to weaker encryption or an unencrypted mode
Common finding: open authentication	An SSID with no authentication, or a captive portal used to reach CUI systems, is typically recorded as NOT MET	Not applicable as a separate finding, but an open network is also a failure of this objective
Common finding: shared passphrases	WPA2-PSK or similar shared passphrases do not identify individual users or devices and are commonly found on staff networks	Shared keys are weak evidence for encryption management because the key must be changed whenever someone with knowledge leaves
Common finding: weak cipher settings	Mixed mode SSIDs that allow fallback to a weaker method are a frequent gap in the evidence	Legacy protocol versions or weak cipher suites enabled alongside approved ones are commonly flagged
What to confirm before the assessment	Which SSIDs can reach the CUI environment, and whether every one of them uses individual authentication	Whether the cipher configuration is documented with the FIPS-validated module used, and confirm the exact module with your vendor

Steps to move a wireless network from shared key to enterprise authentication

This sequence takes a Wi-Fi network that relies on a shared passphrase and replaces it with per-user or per-device authentication, with cryptography and configuration documented well enough for an assessor to test AC.L2-3.1.17. Each step closes with an output the organization can hand to the assessor.

Inventory every wireless network touching the CUI boundary
The organization, usually its IT or network team, lists every access point, controller, SSID and wireless bridge that connects to a system in the CUI boundary, including guest and temporary networks that share infrastructure with it. For each SSID, record the security mode currently configured, who administers it and where the access point is located. The step is done when the list matches what is physically deployed, which a site walk-through or controller export can confirm. This inventory also feeds the wireless authorization requirement AC.L2-3.1.16, so it should be kept current.
Decide the authentication design
The organization decides which in-scope SSIDs will use WPA2 Enterprise or an equivalent enterprise method, with a RADIUS server or similar authentication service that checks each user or device against an identity source. The CMMC Assessment Guide contrasts a shared passphrase, which must be changed whenever someone leaves, with per-user authentication, so the design should show how individual accounts are issued, disabled and reviewed. Confirm with the wireless vendor which enterprise modes the hardware supports before committing. The output is a short design record naming the SSIDs, the authentication server and the identity source.
Confirm FIPS-validated cryptography under SC.L2-3.13.11
The organization checks that the access points, controllers and RADIUS server use cryptographic modules validated under FIPS 140 and that the enabled ciphers and modes fall within what SC.L2-3.13.11 requires. Ask the vendor for the module validation certificate numbers and the exact product versions and firmware they cover, then compare them against the configuration. Confirm the claim with the vendor and the certificate database rather than relying on marketing material. The output is a cryptography record that ties each device to its validation status, which the assessor will test alongside the wireless configuration.
Build the RADIUS and identity integration
An administrator configures the access points or controller to send authentication requests to the RADIUS server, and the server to validate users against the directory the organization already uses for account management. Accounts should map to the same identities used for other CUI systems so that disabling a person in the directory removes wireless access as well. Test with a small group of accounts and confirm that a disabled account is refused. The output is a working test log showing accepted and rejected authentication attempts, plus the server configuration exported for the evidence file.
Disable open and shared-key access on in-scope SSIDs
Once the enterprise SSID works in testing, the administrator removes open authentication and any shared passphrase from every in-scope SSID, including any legacy SSID kept for devices that cannot yet join the enterprise network. Where a legacy SSID must stay, it should be moved outside the CUI boundary and separated at the network layer. The step is done when a controller or access point export shows that no in-scope SSID accepts open or pre-shared key authentication. Keep the before and after exports, because assessors compare configurations at both points.
Verify encryption and the authentication path
The organization runs a verification pass from both an authorized device and an unauthorized one, confirming that the authorized device joins through enterprise authentication with encrypted traffic and that the unauthorized one is refused. It also checks that the access point configuration shows the encryption setting in use on each in-scope SSID. Record the date, the tester, the devices used and the results. The output is a signed test record that supports both assessment objectives in SP 800-171A: protecting wireless access with authentication and protecting it with encryption.
Document the configuration and retain audit records
The organization updates the system security plan and the wireless implementation procedures to describe the authentication design, the RADIUS server, the cryptographic modules, the SSID inventory and the change control for future wireless changes. It also confirms that wireless authentication events are written to audit logs and retained. Ask an independent assessor or the organization's own reviewer to check that the documents match the live configuration. The output is a final configuration package, dated and approved, that an assessor can test against AC.L2-3.1.17 without needing an explanation from the engineer who built it.

Why authentication and encryption must both hold on the same wireless path

AC.L2-3.1.17 is not met by encryption alone or by authentication alone. The assessment breaks the requirement into two objectives in NIST SP 800-171A: protecting wireless access to the system with authentication, and protecting it with encryption. An assessor will look for both on the same wireless path into the CUI environment. A network that encrypts every frame but lets any device with the shared passphrase join has not met the authentication objective, and a network that requires a login but sends traffic in the clear has not met the encryption objective. Both mechanisms must be configured on the path that carries CUI, and the evidence must show them working together.

Enterprise authentication is what separates a defensible design from a shared secret. In the CMMC Assessment Guide's comparison, WPA2-PSK relies on one passphrase that everyone knows, so it must change whenever someone leaves, and it cannot tell one user or device from another. WPA2 Enterprise authenticates each user or device individually, usually through a RADIUS server that is itself a system the assessor will ask about. Open authentication is not acceptable under the guide, and the cryptography has to meet the FIPS-validated standard referenced by SC.L2-3.13.11. Before you commit to a design, confirm with your access point vendor and your RADIUS product which modes they support, whether their cryptographic modules carry FIPS validation, and which configuration settings you can export as evidence.

This requirement connects to AC.L2-3.1.16, which asks you to identify access points and authorize wireless access before any connection is allowed. Authorization decides which devices may join. Authentication and encryption decide how those devices prove who they are and how their traffic is protected. Assessors test the mechanisms, not the policy document: they will review access point and RADIUS configuration, authentication records, and audit logs showing that unauthorized devices were refused, and they will check that the wireless segment sits on the correct side of the CUI boundary. Plan for the day someone adds a new access point or a guest network, because an unmanaged segment bridged to the CUI network can undo an otherwise sound configuration.

Evidence that passes an AC.L2-3.1.17 assessment

Assessors test AC.L2-3.1.17 by reading documents and inspecting the wireless mechanisms themselves, so the evidence must agree with what is actually configured on the network. The cards below cover the artifacts that tie policy, configuration and audit records together for the two assessment objectives: authentication and encryption of wireless access.

Wireless implementation and usage procedures

These are the written procedures that describe how wireless access is implemented and how staff must use it. For AC.L2-3.1.17, they should name the authentication method for each wireless network, state that open authentication is not permitted, and identify who approves changes to the wireless design. Confirm that the approved version is dated, owned, and matches the live configuration. A draft or an undated revision will not satisfy the assessor.

Controller and access point configuration exports

Export the running configuration from wireless controllers and access points and keep dated copies. Assessors look for the security mode set on each SSID, confirmation that no network accepts open authentication, and consistent settings across sites. Exports should be taken after the final change window and stored under change control so the reviewer can see the configuration that was in force on the assessment date.

RADIUS and authentication settings

For enterprise wireless, the RADIUS server and its policy define how each user or device is authenticated. Keep exports of the RADIUS client definitions, authentication policies, and the list of directory groups permitted to join each network. Show that a shared passphrase is not the access method for CUI networks, and confirm that the certificate trust chain and server validation are documented. Account removal should flow through the directory so a departing user loses wireless access.

Cipher and encryption configuration

Assessors check that wireless traffic uses approved cryptography, and the CMMC Assessment Guide ties this to SC.L2-3.13.11 and FIPS-validated modules. Record the cipher suites enabled on each network, the protocol versions allowed, and the FIPS validation certificate that covers the module in use. Confirm with the vendor which validated module version applies to your hardware and firmware, because validation status depends on the specific build.

Audit records of wireless connections

Logs of wireless association, authentication success and failure, and rejected devices show that the protections operate in practice. Retain these records under the audit and accountability controls and review samples on a schedule. Assessors often ask for a log entry that shows an unauthorized or expired credential being refused, so keep those events and confirm that log retention covers the assessment period.

Keeping evidence current between assessments

Evidence degrades when configurations change without records. Tie each export and procedure to a review cycle, a change ticket, and a named owner, and re-export after every wireless change. Keep superseded versions so the history of each setting can be shown. Drafts do not count toward a MET determination, so finalize each artifact, approve it, and date it before the assessment begins.

What meeting AC.L2-3.1.17 costs in money and effort

This table breaks down the cost and effort components of protecting wireless access for AC.L2-3.1.17, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request and to separate internal labor from outside spend. No prices are stated because none are supplied for this requirement, so confirm figures against written scope and vendor quotes.

Cost component	Who is paid or who bears it	One-time or recurring	What drives the cost
Wireless hardware or controller upgrade	Hardware vendor or reseller, if current access points cannot do enterprise authentication	One-time, with refresh cycles	Number of access points, sites, and whether existing gear supports WPA2 Enterprise with RADIUS
RADIUS server and identity integration	Internal IT, platform engineering, or an implementation partner for open-source components	One-time build, then recurring operations	Whether an identity directory already exists, number of directory sources, and certificate handling
Certificates for wireless clients and servers	Internal PKI team or the certificate authority platform	One-time setup, recurring issuance and renewal	Number of client device types, certificate lifetime, and whether issuance is automated
Configuration and testing engineering	Internal network engineers or a contracted implementation partner	One-time, with periodic retesting after changes	Number of SSIDs, site variations, and how much mixed device testing is needed
Evidence collection and upkeep	Internal compliance and IT staff	Recurring	How often configurations change, whether audit records are retained centrally, and how quickly evidence is produced
Removal of shared passphrase access	Internal help desk and IT operations	One-time migration, then recurring user support	Number of users and devices that currently rely on a shared key and must re-enroll
Software licensing	Commercial wireless controller or RADIUS vendor, where used	Recurring license or support fees	Vendor choice; self-hosted open-source components can reduce license spend but still require operating staff
External review and assessor fees	Independent assessor or certification body, not DeployOpen	Per assessment cycle	Assessment scope, number of sites in scope, and whether evidence is organized before the assessment begins

Who owns wireless access protection, who can help, and what the auditor will not do

Your organization owns AC.L2-3.1.17 in full. Leadership must decide how wireless access is protected, which wireless networks are permitted to reach systems that handle CUI, and who is accountable when a configuration drifts. The requirement is not satisfied by a vendor's product alone, because assessors test whether the protections are implemented, configured and documented for your environment.

Accountable owner: Name a person who approves the wireless authentication design and signs off on changes to it.
Authentication choice: Decide whether shared-key WPA2-PSK is acceptable for any segment that touches CUI, or whether enterprise authentication is required.
Policy and procedures: Write the wireless implementation and usage procedures that assessors will ask to see.
Evidence retention: Keep configuration exports, change records and audit records in final form, not drafts.
Staff handling: Define what happens to shared credentials when someone leaves.

Before engaging anyone, confirm internally who will sign the System Security Plan entry for wireless access and who will answer assessor questions on the day.

Where wireless configurations usually fail the test

Wireless failures under AC.L2-3.1.17 rarely come from missing technology. They come from networks that were never separated from CUI, credentials that outlived the people who held them, and documents that describe a design the live access points do not follow. Each card below names one gap, why assessors catch it, and how to close it before the assessment.

WPA2-PSK on guest or legacy SSIDs

A guest or legacy network that uses WPA2 with a shared passphrase can reach the same segment as systems that handle CUI. The CMMC Assessment Guide contrasts this shared-key model with enterprise authentication, which identifies each user or device. Check every SSID, including retired ones still broadcasting, and confirm that none bridges into the CUI boundary. Close the gap by moving CUI-adjacent SSIDs to enterprise authentication and isolating guest traffic at the firewall.

Passphrases not rotated after departures

A shared passphrase is only as safe as the last person who knew it. When an employee, contractor or vendor leaves, the key remains valid unless someone changes it and records the change. Assessors ask how departures trigger rotation and look for a dated change record. Close the gap by tying the wireless credential to the offboarding checklist, or by replacing the shared key with per-user enterprise credentials that expire when the account is disabled.

Access points missing from the inventory

An access point that is not in the asset inventory cannot be authorized, monitored or configured to standard. Consumer routers, temporary extenders and access points installed by facilities teams are common causes. Assessors compare the physical survey or controller data with the inventory and the authorization records. Close the gap by running a wireless discovery sweep, reconciling the results with the inventory, and removing or authorizing every unknown device before the assessment.

Plans that do not match live settings

A wireless standard that describes WPA2 Enterprise while the controller still runs an older open or shared-key profile will fail. SP 800-171A lists implementation procedures, configuration settings and audit records as potential evidence, and assessors may test the mechanism directly. Export the running configuration from each controller and access point, compare it with the documented baseline, and keep the dated export as evidence. Close the gap by correcting the configuration first, then updating the document to match.

Encryption that falls outside FIPS validation

Wireless encryption must meet the cryptography expectations of SC.L2-3.13.11, which means FIPS-validated modules. A strong-sounding protocol can still fail if the access point or controller does not run a validated cryptographic module in the mode used. Ask each vendor for the validation certificate that covers the exact firmware and mode deployed, and record the mode in the configuration evidence. Confirm this with the vendor, since validation status depends on version and configuration.

Questions buyers ask about AC.L2-3.1.17 wireless access protection

Can a shared Wi-Fi key pass AC.L2-3.1.17?

A shared key can appear in an assessed design, but it is the weakest fit for this requirement, and the outcome depends on how the assessor tests it. The CMMC Assessment Guide for Level 2 contrasts WPA2-PSK, where one shared passphrase must change whenever an employee leaves, with WPA2 Enterprise, which authenticates each user or device, typically through a RADIUS server. The guide also says open authentication must not be used and that the cryptography must meet SC.L2-3.13.11. Expect the assessor to ask who can join the network, how the passphrase is rotated after departures, and what records show that rotation happened. Confirm your approach with your assessor before you depend on it.

What does the internal team need to provide for wireless evidence?

The internal team owns the evidence, and assessors usually look for five parallel parts:

A current inventory of wireless access points, with the networks they broadcast and the sites they serve
Written wireless implementation and usage procedures that match the configured design
Exported access point or controller settings showing the authentication method and encryption mode
Audit records of wireless connections and configuration changes
A named owner for each passphrase, RADIUS account or certificate, with the rotation steps written down

Assessors test the mechanisms that implement the protections, so the exported settings matter more than a diagram. Keep the evidence in final form, because drafts do not count toward a MET result.

Is an outside partner required to meet this requirement?

No partner is required to meet AC.L2-3.1.17. The organization owns its controls and its wireless configuration, and it can prepare the evidence itself for a self-assessment. For a Level 2 certification assessment, an independent C3PAO authorized by The Cyber AB performs the assessment and issues the result, which means no consultant can issue it. An implementation partner such as DeployOpen can help plan, configure and document self-hosted supporting systems inside your environment, and help assemble evidence, but it does not issue assessment reports or certificates. Many wireless access points are commercial hardware, so confirm with the vendor which settings and logs your model exposes before you commit to a design.

How long does it take to validate wireless configuration changes?

No general duration can be given, because the time depends on the number of sites, the access point or controller model, and whether the change moves the network from a shared key to enterprise authentication. A simple passphrase rotation is far less work than a move to per-user authentication with a RADIUS server, certificates and client enrollment. Plan time for testing each site, collecting settings exports, and confirming that the final evidence matches the configuration. Ask any implementation partner for a fixed-scope plan with written milestones, and ask your assessor which evidence formats they accept before you begin.

Can AC.L2-3.1.17 be placed on a POA&M?

No. AC.L2-3.1.17 is a 5-point requirement under the CMMC Scoring Methodology, and 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a plan of action and milestones. It must be MET to reach Conditional or Final Level 2 status. If it is NOT MET, its 5 points are subtracted from the maximum score of 110. Plan the wireless design and its evidence before the assessment, not after it, and confirm the scoring treatment with your assessor or the rule text in 32 CFR Part 170.

What changes for wireless access under the Phase II suspension?

The requirement does not change, but the timing and enforcement do. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start on 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. The suspension started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO page, as of 17 October 2026, says implementation is paused and may only require self-assessments at Levels 1 and 2, while the eCFR text still shows the original schedule. Confirm current requirements with your contracting officer, and treat AC.L2-3.1.17 as an ongoing obligation under DFARS 252.204-7012 either way.

Which cryptography must protect the wireless link?

The wireless link must use cryptography that meets the FIPS-validated standard referenced by SC.L2-3.13.11, and open networks do not satisfy the requirement. Ask your access point vendor for the FIPS validation certificate for the exact model and firmware, and confirm that the FIPS mode is enabled and recorded in the configuration export. For enterprise authentication, the certificates used by the RADIUS server and client devices must come from a trusted internal authority. An internal CA such as the one in FreeIPA, which is based on Dogtag, can issue those certificates, but confirm with the access point vendor that its supplicant and RADIUS setup support the certificate method you choose.

How DeployOpen approaches wireless access protection in self-hosted environments

DeployOpen's role on AC.L2-3.1.17 is to prepare the wireless environment so the organization can show both halves of the requirement, authentication and encryption, with configuration evidence an assessor can test. The work starts with scoping the wireless boundary: which access points, controllers and SSIDs touch systems that handle CUI, which networks they bridge to, and whether any guest or contractor network shares hardware with them. We document that boundary in the system security plan inputs so the assessor sees the same scope the organization claims. The organization owns the decision about which wireless designs are acceptable and remains responsible for the control.

Where the design calls for enterprise authentication, DeployOpen can deploy or harden a RADIUS service and a certificate authority inside the client's own cloud account, data center or air-gapped network. FreeIPA, which includes an integrated certificate authority based on Dogtag, is one self-hosted option for issuing and managing the certificates that wireless clients and the RADIUS server present. OpenBao's PKI secrets engine is another option for issuing short-lived X.509 certificates to services. Which combination fits depends on the client's identity platform, device fleet and access point hardware, and the client should confirm that each component and its cryptographic modules meet the FIPS-validated requirement in SC.L2-3.13.11 before selecting it. Shared-key designs such as WPA2-PSK should be retired from CUI segments, because the shared passphrase has to change whenever someone leaves.

DeployOpen then prepares the evidence: exported access point and RADIUS configuration showing encryption and authentication settings, certificate issuance and revocation records, wireless implementation and usage procedures, and audit records of connection attempts. We run a configuration check against the design and record the results, but the organization decides whether the evidence is final. DeployOpen does not issue assessment results, attestations or certifications. Those come only from the independent assessor for the assessment in question, so organizations should confirm the evidence format with that assessor before work starts and agree the scope in writing first.

How DeployOpen prepares wireless access evidence for CMMC

DeployOpen works on AC.L2-3.1.17 Wireless access protection by implementing open-source platforms inside the client's own infrastructure and preparing the configuration evidence an assessor will test. The organization owns its controls and its assessment, while DeployOpen prepares the systems and documentation, and only an independent assessor issues a result.

How we scope

Engagements are fixed-scope, with the wireless networks, access points and authentication services covered agreed in writing before work starts.
The written scope names which wireless segments hold or can reach CUI, so the boundary for AC.L2-3.1.17 is clear.
Scope confirms both assessment objectives: authentication of wireless access and encryption of that access.

How we build

Configure enterprise authentication against a RADIUS service rather than a shared passphrase, with per-user or per-device identity.
Set encryption for wireless sessions using cryptography the organization confirms is FIPS-validated, as required under SC.L2-3.13.11.
Restrict open authentication and document each access point's settings so the configuration can be compared against the approved baseline.

How we hand over

Deliver wireless configuration exports, authentication server settings and the procedures that govern wireless use for assessor review.
Provide audit records showing wireless connections and configuration changes, so the evidence can be traced over time.
Document the testing performed and hand over the final-form evidence, since drafts do not satisfy an assessment objective.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
Retainer work can cover reviews of wireless configuration when access points, SSIDs or authentication services change.
Ask your assessor or Registered Practitioner Organization to confirm which evidence formats they accept before handover.