Who Does What, Practice by Practice
The shared-responsibility split for the NIST SP 800-171 wireless and identity practices a CMMC Level 2 assessment touches. What IronWiFi performs, what stays yours, and which evidence each side produces. Free, no form.
What this is, and the one thing it is not
Every row is Shared or Customer. None is IronWiFi alone. That is not modesty, it is how the rule works: a service provider can perform part of a control and produce evidence for it, but it cannot hold a practice on behalf of an assessed organization. If you read any row here as a control you inherit and no longer have to implement, the row has been misread and your assessment will find the gap.
Your assessor determines your scope, not this page. This describes the standard multi-tenant service as designed. Your deployment, your configuration and your contract govern what is actually in scope, and a C3PAO tests your system rather than our documentation.
Not a certification, and not legal advice. IronWiFi is not CMMC certified and holds no CMMC assessment. This matrix is written from the published text of NIST SP 800-171 Rev. 2 and 32 CFR Part 170. It has not been reviewed by a C3PAO.
Where the Service Sits Relative to Your CUI Boundary
Read this before the matrix. It decides which half of the matrix you actually need.
The designed position. In a properly segmented deployment IronWiFi sits outside your CUI boundary. It authenticates users and devices and retains authentication and accounting records. Those records are security protection data rather than CUI: they say who connected, when, from which device and through which access point. They do not carry the controlled information itself. On that architecture the service is a security protection asset in your assessment, evaluated against the controls relevant to the security capability it provides, rather than a CUI asset.
What breaks that position. If you configure the service so that CUI traverses or is stored in it, the cloud question under DFARS 252.204-7012 applies instead, and our FedRAMP status governs the answer. We are listed in the FedRAMP Marketplace in the Initial Implementation Phase and are not FedRAMP Authorized or Certified today, so that is a live question for your ISSO rather than a settled one. See our published FedRAMP data.
Practical consequence. Guest and public SSIDs belong outside the CUI boundary and, segmented properly, outside your assessment scope entirely. Staff and device 802.1X on a CUI network must be scoped, logged and isolated. The matrix below assumes the designed position; if your architecture differs, the allocation shifts toward you, never toward us.
The Matrix
Scoped to the practices this service actually touches. The other practices in your assessment are not listed because this service has no part in them, and a matrix padded with "not applicable" rows invites exactly the misreading warned about above.
| Practice | Allocation | IronWiFi performs | You perform | Evidence we can supply |
|---|---|---|---|---|
| AC.L2-3.1.16Authorize wireless access prior to connection | Shared | Enforces that only configured SSIDs and network policies accept connections; per-tenant configuration; admin RBAC over who may change them. | Decide which SSIDs exist and why; authorize the people who get access; record both in your SSP; run the access reviews. | SSID and policy configuration export; admin role assignments; change history. |
| AC.L2-3.1.17Protect wireless with authentication and encryption | Shared | 802.1X authentication with EAP-TLS; WPA2/WPA3-Enterprise support; RadSec for RADIUS over TLS. | Configure the access points to use it, and leave no pre-shared key on any in-scope SSID. The strongest RADIUS in the world does not help an SSID still running a shared password. | RADIUS policy and EAP method configuration; the security mode we see per SSID. |
| IA.L2-3.5.3Multifactor authentication | Mostly yours | Integrates with your identity provider so its MFA decision governs access; supports certificate-based authentication and PIV/CAC. | Own it. The MFA policy is configured and enforced in your IdP, not in the wireless layer. We carry the certificate factor and honour your IdP's decision; we do not decide it. | Integration configuration showing which IdP is authoritative; authentication records showing the method used. |
| IA.L2-3.5.4Replay-resistant authentication | Shared | EAP-TLS, a mutually authenticated TLS handshake with per-session key material; cloud PKI issuance and SCEP enrollment. | Set and enforce certificate lifecycle policy: validity period, renewal threshold, and the triggers for revocation. | Certificate templates and enrollment configuration; issuance and revocation records. |
| AU family (3.3.x)Audit records for wireless access | Shared | Generates authentication and accounting records for every attempt on every configured SSID; on-demand reports; export to your SIEM by webhook and syslog. | Set the retention period, run and document the log reviews, and own the SIEM the records land in. Generating a record is not the same as reviewing it, and the review is the part assessors ask to see. | Sample records with the fields visible; export configuration; the retention setting as configured on your tenant. |
| SC.L2-3.13.8Cryptographic protection in transit | Shared | TLS 1.2/1.3 for authentication exchanges and AES-256 at rest, using FIPS-validated modules on our side; no plaintext credential traverses the network. | Choose the encryption mode on the access points and the FIPS posture of the modules on your side of the link, in line with your own cryptographic policy. | The transport configuration we enforce; SOC 2 Type II report under NDA covering the platform controls. |
Read the "You perform" column as the real deliverable. It is the part an assessor tests and the part no vendor can do for you. If a row's right-hand side is not true of your environment today, that is a finding you have located before your assessor did, which is the cheapest time to find one.
What We Can Send, and What We Cannot
So nobody waits on a document that does not exist
Available on request
SOC 2 Type II report under NDA (unqualified, issued 7 May 2026 by Johanson Group LLP, renewed annually). Your tenant's SSID, policy and RADIUS configuration exports. Sample authentication and accounting records.
Available publicly, no request needed
Our FedRAMP certification data (ID FR2631154499, Initial Implementation Phase). The wireless control mapping. The SSP wireless section template. This matrix.
What we cannot provide
A CMMC certificate for your organization, or one of our own. A FedRAMP authorization letter, because we do not have one yet. An attestation that any practice is satisfied on your behalf. A determination of your assessment scope, which is your assessor's call.
What we will not do
Tell you a control is inherited when it is shared. The short-term sale is not worth the finding it creates in your assessment, and you would be the one holding it.
Make the Left-Hand Column True
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. The right-hand column stays yours, and that is the honest arrangement.