Wireless Section Template for Your SSP
A fill-in-the-blanks structure for the wireless part of a System Security Plan under NIST SP 800-171 Rev. 2, the control set CMMC Level 2 assesses. SSID inventory, authorization narrative, per-practice statements, and the evidence to attach to each one.
Read this before you use any of it
This is a structure, not a completed SSP. Every bracketed field is a decision only you can make, and every sentence you keep becomes a statement your organization makes to the federal government. A self-assessment score posted in SPRS is a representation; a wireless narrative that does not match your network is a false one. Fill it in from what your network actually does, not from what this page assumes.
Nothing here is inherited from IronWiFi. A service provider can supply a control's implementation and its evidence. It cannot hold the practice for you. Where a row below says IronWiFi provides something, that is a component inside your boundary that you are still responsible for configuring, scoping and attesting to.
This has not been reviewed by a C3PAO or any assessor. It is written from the published text of NIST SP 800-171 Rev. 2 and ordinary assessment practice. Your assessor tests your system, not this document. If your assessor or consultant wants it structured differently, follow them, not us.
How to Use It
About an afternoon, if you already know what is on your network
1. Inventory before you write
Fill the SSID table first. Most wireless findings are not a missing control, they are an SSID nobody could account for
2. Replace every bracket
Anything still in [SQUARE BRACKETS] is unfinished. If a statement is not true of your network, delete it rather than soften it
3. Attach the evidence
Each practice below names what an assessor will ask to see. A statement with no artifact behind it is the gap they find
Section 1 — SSID Inventory
This table is most of what AC.L2-3.1.16 asks for. Every SSID broadcasting anywhere in scope gets a row, including the ones you are about to decommission.
| SSID | Purpose | In CUI scope? | Authentication | VLAN / segment | Who authorizes access |
|---|---|---|---|---|---|
| [CORP-SSID] | Staff and managed endpoints | Yes | WPA2/WPA3-Enterprise, 802.1X, EAP-TLS certificate per device | [VLAN ID] | [ROLE, e.g. IT Manager, on [TICKET SYSTEM] request] |
| [ADMIN-SSID] | Privileged administration | Yes | 802.1X plus MFA enforced at [IdP], or PIV/CAC | [VLAN ID] | [ROLE] |
| [GUEST-SSID] | Visitors, internet only | No — segmented out, see Section 4 | Captive portal, no access to internal resources | [VLAN ID] | [ROLE or self-service] |
| [IOT-SSID] | Printers, cameras, building systems | [Yes / No — state which] | [MAC auth / certificate / PSK — be honest here] | [VLAN ID] | [ROLE] |
If a row makes you uncomfortable, that is the finding, and you have found it before your assessor did. A shared pre-shared key on a row marked "In CUI scope: Yes" is the single most common wireless gap in the defense industrial base. Fix the network, then write the row.
Section 2 — Practice Statements
One block per practice. Edit the statement, then attach the evidence named beneath it.
AC.L2-3.1.16 — Authorize wireless access prior to allowing such connections
Wireless access to [SYSTEM NAME] is authorized before connection. Every SSID operating in the environment is listed in Section 1 with its purpose, scope designation, authentication method and authorizing role. New SSIDs are created only through [CHANGE PROCESS], approved by [ROLE]. Access to an in-scope SSID is granted by [ROLE] on [REQUEST PROCESS] and is tied to the user's account in [IDENTITY PROVIDER]. Disabling that account removes wireless access at the next authentication attempt. Access is reviewed [FREQUENCY, e.g. quarterly] by [ROLE].
Evidence to attach: the SSID table from Section 1; the change record for the most recent SSID added or removed; a sample access request and its approval; the most recent access review.
AC.L2-3.1.17 — Protect wireless access using authentication and encryption
In-scope wireless networks use WPA2-Enterprise or WPA3-Enterprise with 802.1X. Each user or device authenticates individually against [RADIUS SERVICE] using EAP-TLS with a certificate issued by [CERTIFICATE AUTHORITY]. No pre-shared key is configured on any SSID marked in scope in Section 1. RADIUS traffic between [ACCESS POINT VENDOR] access points and the authentication service is protected by [RadSec / IPsec / describe the transport]. Certificates are issued and renewed through [ENROLLMENT METHOD, e.g. SCEP via your MDM] and revoked through [PROCESS] when a device is lost or retired.
Evidence to attach: the wireless configuration export showing the security mode per SSID; a screenshot or export of the RADIUS policy; the certificate template or profile; a revocation record.
IA.L2-3.5.3 — Multifactor authentication
Network access to [SYSTEM NAME] requires multiple factors. On in-scope wireless, the device presents a certificate (something you have) and the user authenticates to [IDENTITY PROVIDER], which enforces [SECOND FACTOR, e.g. Entra ID Conditional Access with an authenticator app / PIV/CAC]. The MFA policy is configured and enforced in [IDENTITY PROVIDER], not in the wireless layer. Exceptions are [NONE / list them and the compensating control].
Evidence to attach: the IdP conditional access or MFA policy export; the list of accounts in scope and any exclusions; a sign-in log showing the factors satisfied. Note the split: the wireless layer carries the certificate factor, the IdP enforces the rest. Do not claim MFA on the strength of certificates alone unless your assessor agrees that is sufficient for the account type.
IA.L2-3.5.4 — Replay-resistant authentication
Wireless authentication for privileged and non-privileged accounts uses EAP-TLS, a mutually authenticated TLS handshake with per-session key material, which is resistant to replay. Certificate lifecycle is governed by [POLICY REFERENCE]: issued for [VALIDITY PERIOD], renewed at [THRESHOLD], revoked on [TRIGGERS].
Evidence to attach: the certificate policy or CPS section covering validity, renewal and revocation; a current CRL or OCSP response; the EAP method configured on the RADIUS policy.
AU family (3.3.x) — Audit records for wireless access
Every wireless authentication attempt on an in-scope SSID generates a RADIUS authentication and accounting record containing the identity presented, the result, the timestamp, the device identifier and the access point. Records are retained for [RETENTION PERIOD] in [SYSTEM], forwarded to [SIEM] by [webhook / syslog], and reviewed [FREQUENCY] by [ROLE]. Retention, review and the integrity of the SIEM are the responsibility of [ORGANIZATION], not of the wireless service provider.
Evidence to attach: a sample authentication and accounting record with the fields visible; the SIEM ingestion configuration; the retention setting; a dated record of the most recent log review. Retention is the field people leave blank. Pick a period, write it down, and make sure the system is actually configured that way.
SC.L2-3.13.8 — Cryptographic protection in transit
CUI traversing the wireless network is protected in transit. The wireless link uses [WPA2-Enterprise / WPA3-Enterprise] with AES-CCMP. Authentication exchanges are carried over TLS [1.2 / 1.3]. Cryptographic modules in use are [NAME THE MODULES AND THEIR VALIDATION STATUS], selected in line with [YOUR CRYPTO POLICY REFERENCE].
Evidence to attach: the encryption mode per SSID from the controller export; the TLS versions in use; your cryptographic module inventory. Be precise about validation. "FIPS-validated module" and "FIPS-compatible configuration" are different claims and an assessor will know the difference. State whichever is actually true of the module on your access points.
Section 3 — Scope and Boundary Statement
The cheapest control you own. Written properly, this removes the guest network from the assessment entirely.
Guest network exclusion
[GUEST-SSID] is excluded from the CUI boundary. It is carried on VLAN [ID], which is routed directly to the internet through [DEVICE] and has no route to any system that stores, processes or transmits CUI. The isolation is enforced by [ACL / firewall policy / describe it] and was last verified on [DATE] by [METHOD, e.g. an attempted connection from the guest VLAN to an in-scope host]. Guest users receive no credential that grants access to any in-scope system.
Evidence to attach: the firewall or ACL rule enforcing the isolation; the routing configuration; a dated test result showing the guest VLAN cannot reach an in-scope host. Claim the exclusion only if you have tested it. An untested isolation claim that fails under an assessor's traffic test pulls the guest network back into scope and calls the rest of the narrative into question.
Section 4 — Evidence Checklist
What to have in the folder before anyone asks
SSID inventory, dated
The table from Section 1, with a revision date and an owner.
Controller or AP configuration export
Showing security mode and RADIUS server per SSID.
RADIUS policy and EAP method
Proving individual authentication rather than a shared secret.
Certificate policy and a revocation record
Validity, renewal, revocation, and evidence the process has been used.
IdP MFA policy and a sign-in log
Showing which factors were satisfied for an in-scope account.
Authentication log sample plus retention setting
One real record with the fields visible, and the configured retention period.
Guest isolation rule and a dated test
The rule itself, and proof somebody checked it holds.
Access review record
Who reviewed wireless access to in-scope SSIDs, when, and what changed.
If the SSID Table Is the Problem, We Can Fix That Part
Most of this template is yours to write. The rows that say 802.1X, EAP-TLS, per-user certificates and RADIUS audit records are the part IronWiFi supplies, on the access points you already own. IronWiFi is not CMMC certified and cannot hold a practice for you, but it can make these statements true.