Protecting controlled unclassified information (CUI) on wireless networks is a high-priority requirement under NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 (Control AC.L2-3.1.17); the recommended, practical way to meet that requirement is to deploy WPA3-Enterprise with a RADIUS backend using certificate-based EAP (EAP-TLS) and hardened access point and RADIUS configurations.
\n\nWPA3-Enterprise provides stronger encryption (GCMP) and mandatory management frame protection (PMF) compared with legacy WPA/WPA2 modes; pairing it with a RADIUS server that enforces EAP-TLS gives you mutual authentication via X.509 certificates, eliminates reliance on shared passphrases, and produces audit records for authentication events — all outcomes that align with NIST/CMMC expectations for strong authentication and encryption for wireless access.
\n\nAt a practical level, implementers should follow these steps: (1) inventory APs and verify firmware supports WPA3-Enterprise (or plan hardware refresh), (2) deploy or subscribe to a RADIUS service (FreeRADIUS, Microsoft NPS, Cisco ISE, cloud RADIUS/NPS extension), (3) establish a PKI (internal CA or enterprise CA) and issue server and client certificates, (4) configure RADIUS to require EAP-TLS, (5) configure SSIDs on APs for WPA3-Enterprise pointing to RADIUS, (6) harden ciphers, require PMF, disable legacy fallbacks, and (7) enable logging, monitoring, and certificate lifecycle processes (CRL/OCSP, renewal automation).
\n\nSmall-business-friendly example: FreeRADIUS on a Linux VM + internal CA using OpenSSL. Create a CA, issue a RADIUS server certificate (subjectAltName with FQDN), and generate client certificates for devices or use MDM/SCEP to enroll laptops and phones. Configure eap.conf (or mods-enabled/eap) to use eap = tls and point to the server cert and private key. In FreeRADIUS clients.conf, add each AP with a long shared secret and restrict access by IP. On APs, create an SSID using WPA3-Enterprise, set RADIUS server IP/port (1812) and shared secret, select 802.1X authentication with EAP, and require PMF and AES-GCMP (avoid TKIP).
\n\nExample OpenSSL commands (simplified) to create CA and server cert:
openssl genrsa -out ca.key 4096\nopenssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj \"/CN=MyInternalCA\"\nopenssl genrsa -out radius.key 2048\nopenssl req -new -key radius.key -out radius.csr -subj \"/CN=radius.example.local\"\nopenssl x509 -req -in radius.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out radius.crt -days 825 -sha256 -extfile v3ext.cnf\nFor compliance and security, use EAP-TLS (mutual certs) as the primary EAP method. Avoid EAP-PEAP/MSCHAPv2 unless you have strong MFA and legacy client constraints. Configure TLS to accept only strong keys: prefer ECC P-256 or RSA 3072/4096 for server keys, and require TLS 1.2+ with strong ciphers. On the Wi‑Fi side, select WPA3-Enterprise (128-bit) or WPA3-Enterprise 192-bit mode if you need higher assurance; ensure the AP enforces AES-GCMP (GCMP-128 or GCMP-256) and that Management Frame Protection is required (802.11w required).
\n\nCompliance requires not just initial configuration but ongoing operational controls: time synchronization (NTP) across APs and RADIUS for certificate validation; CRL / OCSP publishing and RADIUS OCSP checks if you revoke client certs; log authentication attempts and failures and forward to a central syslog/SIEM for retention consistent with your policy (NIST often expects audit logging and retention to support incident response); and implement monitoring/alerts for spikes in failed authentications or AP configuration changes.
\n\nScenario A — Minimal on-prem: Use a small Linux VM running FreeRADIUS and an internal CA; distribute client certs via an MDM (Intune, Workspace ONE) or manually for a dozen devices. Scenario B — Hybrid/Cloud: Use Azure AD + NPS extension or a cloud RADIUS provider that integrates with your identity provider and uses client certs or device posture checks. Scenario C — Mixed clients: If some IoT devices cannot do EAP-TLS, place them on a segmented guest/VLAN with firewall rules restricting CUI access, and require separate authentication for endpoints handling CUI.
\n\nBest practices: enforce certificate-based authentication (EAP-TLS), automate certificate issuance/renewal via SCEP/MDM, disable WPA/WPA2 personal and TKIP, require PMF, use long RADIUS shared secrets and limit AP management to out-of-band connections, and document configurations and policies. Test with multiple client OS versions and maintain a procedure for revoked certificates. The risks of failing to implement these controls include eavesdropping of wireless traffic, rogue APs and credential theft when PSKs are used, lateral movement into CUI repositories, failed audits, loss of DoD contracts, and legal/financial penalties for non-compliance.
\n\nSummary: To meet AC.L2-3.1.17 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2, implement WPA3-Enterprise with a RADIUS server enforcing EAP-TLS, strong certificate lifecycles, hardened AP settings (PMF and AES-GCMP), centralized logging, and operational processes for monitoring and certificate revocation; for small businesses, this can be achieved with FreeRADIUS or cloud/NPS solutions combined with an MDM for certificate distribution, delivering both the technical protections and the documented controls auditors expect.
", "plain_text": "Protecting controlled unclassified information (CUI) on wireless networks is a high-priority requirement under NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 (Control AC.L2-3.1.17); the recommended, practical way to meet that requirement is to deploy WPA3-Enterprise with a RADIUS backend using certificate-based EAP (EAP-TLS) and hardened access point and RADIUS configurations.\n\nWhy WPA3-Enterprise + RADIUS (EAP-TLS) meets the compliance objective\nWPA3-Enterprise provides stronger encryption (GCMP) and mandatory management frame protection (PMF) compared with legacy WPA/WPA2 modes; pairing it with a RADIUS server that enforces EAP-TLS gives you mutual authentication via X.509 certificates, eliminates reliance on shared passphrases, and produces audit records for authentication events — all outcomes that align with NIST/CMMC expectations for strong authentication and encryption for wireless access.\n\nHigh-level implementation plan for a small business\nAt a practical level, implementers should follow these steps: (1) inventory APs and verify firmware supports WPA3-Enterprise (or plan hardware refresh), (2) deploy or subscribe to a RADIUS service (FreeRADIUS, Microsoft NPS, Cisco ISE, cloud RADIUS/NPS extension), (3) establish a PKI (internal CA or enterprise CA) and issue server and client certificates, (4) configure RADIUS to require EAP-TLS, (5) configure SSIDs on APs for WPA3-Enterprise pointing to RADIUS, (6) harden ciphers, require PMF, disable legacy fallbacks, and (7) enable logging, monitoring, and certificate lifecycle processes (CRL/OCSP, renewal automation).\n\nConcrete technical details and example configurations\nSmall-business-friendly example: FreeRADIUS on a Linux VM + internal CA using OpenSSL. Create a CA, issue a RADIUS server certificate (subjectAltName with FQDN), and generate client certificates for devices or use MDM/SCEP to enroll laptops and phones. Configure eap.conf (or mods-enabled/eap) to use eap = tls and point to the server cert and private key. In FreeRADIUS clients.conf, add each AP with a long shared secret and restrict access by IP. On APs, create an SSID using WPA3-Enterprise, set RADIUS server IP/port (1812) and shared secret, select 802.1X authentication with EAP, and require PMF and AES-GCMP (avoid TKIP).\n\nExample OpenSSL commands (simplified) to create CA and server cert: openssl genrsa -out ca.key 4096\nopenssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj \"/CN=MyInternalCA\"\nopenssl genrsa -out radius.key 2048\nopenssl req -new -key radius.key -out radius.csr -subj \"/CN=radius.example.local\"\nopenssl x509 -req -in radius.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out radius.crt -days 825 -sha256 -extfile v3ext.cnf\nThen configure FreeRADIUS to use radius.crt/radius.key and trust the CA certificate.\n\nRecommended RADIUS/EAP choices and cipher settings\nFor compliance and security, use EAP-TLS (mutual certs) as the primary EAP method. Avoid EAP-PEAP/MSCHAPv2 unless you have strong MFA and legacy client constraints. Configure TLS to accept only strong keys: prefer ECC P-256 or RSA 3072/4096 for server keys, and require TLS 1.2+ with strong ciphers. On the Wi‑Fi side, select WPA3-Enterprise (128-bit) or WPA3-Enterprise 192-bit mode if you need higher assurance; ensure the AP enforces AES-GCMP (GCMP-128 or GCMP-256) and that Management Frame Protection is required (802.11w required).\n\nOperational controls, logging and lifecycle management\nCompliance requires not just initial configuration but ongoing operational controls: time synchronization (NTP) across APs and RADIUS for certificate validation; CRL / OCSP publishing and RADIUS OCSP checks if you revoke client certs; log authentication attempts and failures and forward to a central syslog/SIEM for retention consistent with your policy (NIST often expects audit logging and retention to support incident response); and implement monitoring/alerts for spikes in failed authentications or AP configuration changes.\n\nSmall-business scenarios and deployment options\nScenario A — Minimal on-prem: Use a small Linux VM running FreeRADIUS and an internal CA; distribute client certs via an MDM (Intune, Workspace ONE) or manually for a dozen devices. Scenario B — Hybrid/Cloud: Use Azure AD + NPS extension or a cloud RADIUS provider that integrates with your identity provider and uses client certs or device posture checks. Scenario C — Mixed clients: If some IoT devices cannot do EAP-TLS, place them on a segmented guest/VLAN with firewall rules restricting CUI access, and require separate authentication for endpoints handling CUI.\n\nCompliance tips, best practices, and risks of non-implementation\nBest practices: enforce certificate-based authentication (EAP-TLS), automate certificate issuance/renewal via SCEP/MDM, disable WPA/WPA2 personal and TKIP, require PMF, use long RADIUS shared secrets and limit AP management to out-of-band connections, and document configurations and policies. Test with multiple client OS versions and maintain a procedure for revoked certificates. The risks of failing to implement these controls include eavesdropping of wireless traffic, rogue APs and credential theft when PSKs are used, lateral movement into CUI repositories, failed audits, loss of DoD contracts, and legal/financial penalties for non-compliance.\n\nSummary: To meet AC.L2-3.1.17 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2, implement WPA3-Enterprise with a RADIUS server enforcing EAP-TLS, strong certificate lifecycles, hardened AP settings (PMF and AES-GCMP), centralized logging, and operational processes for monitoring and certificate revocation; for small businesses, this can be achieved with FreeRADIUS or cloud/NPS solutions combined with an MDM for certificate distribution, delivering both the technical protections and the documented controls auditors expect." }, "metadata": { "description": "Step-by-step guidance for configuring WPA3-Enterprise with RADIUS (EAP-TLS), certificates, and AP settings to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 wireless authentication and encryption requirements.", "permalink": "/how-to-configure-wpa3-enterprise-and-radius-to-meet-nist-sp-800-171-rev2-cmmc-20-level-2-control-acl2-3117-and-protect-wireless-access-with-strong-authentication-and-encryption.json", "categories": [], "tags": [] } }