NIST 800-171 control mapping
For teams preparing for a CMMC Level 2 assessment or already operating under NIST 800-171: which controls PermitUSB satisfies, and to what depth. The auditor language in each section is a starting point for your System Security Plan or POA&M.
Coverage at a glance
PermitUSB is purpose-built for the Media Protection family, with strong supporting coverage in Audit and Accountability and in Configuration Management. Other families are compensating at best: pair PermitUSB with the rest of your security stack.
| Control | Coverage | How |
|---|---|---|
| 3.1.1 Limit system access to authorized users | Direct | RBAC, Supabase Auth, per-tenant RLS |
| 3.1.2 Limit access to types of transactions | Direct | Role capabilities: owner, admin, operator, auditor |
| 3.1.5 Least privilege | Direct | Per-role capability set. The auditor role is read-only |
| 3.1.21 Limit portable storage on external systems | Direct | Mass-storage class blocking (USBSTOR, UASPStor, SCSIAdapter) plus per-serial allow lists |
| 3.3.1 Audit logs | Direct | events and admin_audit_log tables |
| 3.3.2 Unique user identification in logs | Direct | actor_user_id on every admin audit row |
| 3.3.3 Audit log review | Direct | Audit log with filters and CSV/JSON export, plus curated reports |
| 3.3.7 Time-stamped audit records | Direct | Server-side created_at on every row |
| 3.3.8 Protect audit information | Direct | Tenant isolation through Postgres RLS |
| 3.3.9 Limit audit management to privileged users | Direct | The audit_log.read capability gates the route |
| 3.4.6 Essential capabilities only | Direct | Class-based deny by default, per-group allow rules |
| 3.4.7 Restrict nonessential functions | Direct | Same enforcement as 3.4.6 |
| 3.5.1 Identify users | Direct | Supabase Auth |
| 3.5.2 Authenticate users | Direct | Password with TOTP MFA, or a passkey |
| 3.5.3 MFA for privileged accounts | Direct | TOTP or passkey at sign-in, with a workspace-wide require_mfa flag |
| 3.6.2 Track and report incidents | Direct | Tamper events with email and webhook alerting |
| 3.8.7 Control removable media | Direct | Block-by-default policy engine, events logged with full device fingerprint |
| 3.8.8 Prohibit unidentifiable portable storage | Direct | Per-device serial allow-listing, warning on non-unique serials |
| 3.13.1 Boundary protection | Partial | USB is one boundary. Complements network boundary tools |
| 3.13.8 Encrypt CUI in transit | Direct | TLS 1.3 agent to cloud, HSTS on the dashboard |
| 3.13.11 FIPS-validated cryptography | Partial | DPAPI on the agent. Confirm provider validation with your assessor |
| 3.13.13 Control mobile code | Partial | Constrains the USB vector. Pair with EDR for the executable side |
| 3.14.1 Identify, report, correct flaws | Partial | Tamper detection and watchdog correction. OS patching is yours |
| 3.14.6 Monitor systems | Partial | Continuous USB event monitoring. Pair with EDR or SIEM |
| 3.14.7 Identify unauthorized use | Direct | Every block event logged, with optional alert and reports |
3.1.21 Limit use of portable storage devices on external systems
Direct mapping. Block-by-default whitelisting on the mass-storage classes, USBSTOR for bulk-only transport devices and UASPStor and SCSIAdapter for UAS devices such as most modern external SSDs, plus per-device serial allow-listing, implements exactly this control’s intent: portable storage is used only on endpoints where the organization has explicitly approved the device.
3.4.6 Essential capabilities only
Class-based deny by default enforces essential capabilities only at the USB layer. Endpoint groups let you express a different essential set per role: one group allowing storage from approved vendors, another allowing printers and audio only, a locked-down group allowing nothing beyond input devices.
3.8.7 Control the use of removable media
Direct mapping. Removable media is controlled by the policy engine, and every plug and unplug event is logged with the full device fingerprint: VID, PID, serial, class, friendly name and vendor manufacturer string.
3.8.8 Prohibit portable storage with no identifiable owner
Per-device serial allow-listing identifies the owner. The dashboard surfaces a warning when a device reports a non-unique serial number, a common cheap-thumb-drive pattern, so administrators can recognize un-ownable devices and disallow them explicitly.
3.3 Audit and accountability
Two log streams: device events, covering every USB plug with the action taken, and an admin audit log covering every policy, token, role and billing change. Default retention is 365 days on the Paid plan, and both export to CSV or JSON. Timestamps are set server-side at insert, so a manipulated local clock on a compromised endpoint cannot corrupt the trail.
3.3.2 Unique user identification in logs
Every admin audit row carries an actor_user_id uniquely identifying the Supabase Auth user that performed the action.
3.3.3 / 3.3.6 Audit review and analysis
The audit-log page filters by actor, action prefix and date range, with CSV and JSON export. The events page does the same for device-level events. The reports page adds curated aggregates, blocked devices, silent endpoints, tamper and protection pauses, and a full-history export with an explicit date-range builder: the artifact an assessor asks for, rather than a dashboard to filter.
3.3.8 / 3.3.9 Protecting and restricting the audit trail
Audit data is protected by Postgres row-level security: a cross-tenant query returns no rows. The service-role key that bypasses RLS is held only by the PermitUSB API, never by customer-facing code. Reading the audit log requires the audit_log.read capability, which the auditor, admin and owner roles hold and the operator role does not.
3.5 Identification and authentication
Identification and authentication are delegated to Supabase Auth. Email and password is the default mechanism and password complexity follows Supabase’s NIST-aligned policy. A passkey is an alternative, and it satisfies the multifactor requirement on its own.
For 3.5.3, TOTP multifactor is enrolled per user and challenged at every sign-in once a factor is verified. Tenant owners can require it workspace-wide through the require_mfa flag: members without a factor are redirected to enroll before they can use the dashboard. Sensitive admin actions, such as resetting another user’s MFA or toggling the workspace requirement, need step-up re-authentication. Each enrollment issues ten single-use recovery codes for the lost-device case.
3.6 Incident response
Tamper events, meaning service-stop attempts, watchdog re-disable, refresh-token replay and policy-stale, are logged to the cloud and routed to email or webhook channels per the tenant’s alerting configuration. Block events on policies marked sensitive take the same alert path.
3.13 System and communications protection
USB is one boundary among many. PermitUSB controls that boundary; pair it with network firewalls, DNS filtering and EDR for the boundaries it does not address.
- 3.13.8, encrypt CUI in transit: all agent-to-cloud and dashboard-to-cloud traffic is TLS 1.3 and the cloud surface enforces HSTS. Agent enrollment and token rotation use signed JWTs over the same channel
- 3.13.11, cryptography for protecting CUI: the agent encrypts its cached refresh-token credential at rest with DPAPI scoped to LocalMachine, and cloud-side data sits in Supabase Postgres with provider-level at-rest encryption. PermitUSB implements no cryptography of its own, so FIPS validation status of the underlying TLS and storage providers is something you confirm with your assessor
- 3.13.13, control and monitor mobile code: indirect. Controlling which USB mass storage devices can attach constrains a common delivery vector, but the control’s full intent, governing script and binary execution, needs endpoint anti-malware or EDR. PermitUSB is complementary here, not a replacement
3.14 System and information integrity
Tamper events are the report half of 3.14.1 and the watchdog is the correct half for in-band tampering, re-disabling devices that were re-enabled out of band. Operating system patching stays yours; agent updates are signed MSIs distributed through the dashboard’s authenticated download.
For 3.14.6, the agent runs continuous USB-event monitoring on every managed endpoint, and events surface on the dashboard within about five seconds of plug-in. For 3.14.7, every block event is by definition an unauthorized-use attempt: block events are logged, they fire an immediate alert when the matched policy is marked sensitive, and the blocked-devices report aggregates them per device and endpoint over any date range.
What PermitUSB does not address
PermitUSB is a USB device control product. It should not be cited as primary evidence for these families:
- 3.2 Awareness and Training: entirely a customer program
- 3.7 Maintenance: endpoint maintenance procedures are out of scope
- 3.9 Personnel Security: HR and vetting controls
- 3.10 Physical Protection: site security
- 3.11 Risk Assessment: your security program owns this
- 3.12 Security Assessment: your assessor and SSP process
Within the families it partially covers, these sub-controls need other tools:
- File-content data loss prevention
- BitLocker or disk-encryption enforcement
- Network device control over Ethernet, Wi-Fi or Bluetooth
- Endpoint anti-malware and EDR
- Vulnerability management and patching
- Backup and recovery of customer-side CUI
Asking for help
If your assessor has a question about a specific control mapping, or your SSP needs PermitUSB-specific wording that is not on this page, email compliance@permitusb.com. We will either provide the language directly or update this page so every customer has it.
Something missing or wrong here? Tell us. Documentation gaps get filled fast.