NIST 800-171 control mapping

For organizations preparing for a CMMC Level 2 assessment or already operating under NIST 800-171, this page documents which controls PermitUSB satisfies and to what depth. Use the auditor-ready language at the end of each section as a starting point for your System Security Plan (SSP) or Plan of Action and Milestones (POA&M).

Coverage at a glance

PermitUSB is purpose-built for the Media Protection family with strong supporting coverage in Audit / Accountability and Configuration Management. Other families are compensating at best — pair PermitUSB with the rest of your security stack.

3.1 Access Control

3.1.1 — Limit system access to authorized users

Access to the PermitUSB dashboard requires Supabase Auth credentials. The Postgres RLS layer enforces per-tenant isolation: a user belonging to tenant A cannot read or modify tenant B's policies, events, or audit log even via direct database query.

Auditor language: "Access to the PermitUSB control plane is restricted to authenticated users with a valid Supabase Auth session. Each user is bound to exactly one tenant. Postgres row-level security policies on every tenant-scoped table enforce isolation; queries return only rows where tenant_id = current_tenant_id()."

3.1.2 — Limit access to types of transactions and functions

PermitUSB ships four built-in roles — owner, admin, operator, auditor — each backed by a capability set. Capabilities are checked at the API route level via the requireRole middleware.

Auditor language: "User actions are gated by role-based capabilities. The auditor role is read-only across the entire surface; the operator role can manage endpoints and respond to events but cannot modify policies; admin and owner roles can modify policies and tenant settings respectively. Capability checks are enforced server-side at every mutating API route."

3.1.5 — Employ the principle of least privilege

The default new-tenant role is auditor for invited users; admins are explicitly elevated. The agent runs as LocalSystem only on the endpoint it manages, with no remote-access path back from the agent.

Auditor language: "User roles default to read-only auditor on tenant invitation. Privilege elevation is an explicit administrative action logged toadmin_audit_log. The endpoint agent operates with LocalSystem privilege only on its host and exposes no inbound network surface."

3.1.21 — Limit use of portable storage devices on external systems

Direct mapping. Block-by-default whitelisting on the USBSTOR class 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.

Auditor language: "USB mass storage is enforced via PermitUSB endpoint policy. Default disposition is block; only specific devices on the approved-serials allow list are permitted. Deviations are logged and surfaced via the alert channel within seconds."

3.3 Audit and Accountability

3.3.1 — Create and retain audit logs

PermitUSB writes two log streams: device events (every USB plug, with action taken) and an admin audit log (every policy / token / role / billing change). Default retention is 365 days on the Paid plan.

Auditor language: "All USB device events and administrative actions are recorded in the PermitUSB cloud's events and admin_audit_log tables. Retention is 365 days. Records are exportable in CSV or JSON for ingestion into external SIEM / log archive systems."

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.

Auditor language: "Each admin_audit_log entry records the Supabase Auth UUID of the acting user, enabling per-user attribution of every administrative action."

3.3.3 / 3.3.6 — Audit review and analysis

The dashboard's audit-log page supports filtering by actor, action prefix, and date range, plus CSV / JSON export. The Events page provides the same for device-level events.

Auditor language: "The administrator dashboard provides interactive review of audit records with filters by actor, action type, and date range. Export to CSV or JSON is supported for offline analysis or SIEM ingestion."

3.3.7 — Time-stamped audit records

Every event and audit row has a server-side created_at set at insert time. Time source is the cloud database, not the agent — preventing local-clock manipulation on a compromised endpoint from corrupting the audit trail.

3.3.8 — Protect audit information

Audit data is protected by Postgres row-level security: cross-tenant queries return no rows. The service-role key (which bypasses RLS) is held only by the PermitUSB API, never by customer-facing code.

3.3.9 — Limit audit log management to privileged users

The /api/audit-log route requires the audit_log.read capability. The auditor role has read; admin and owner roles have read; operator does not have read by default and would need explicit role elevation.

3.4 Configuration Management

3.4.6 — Essential capabilities only

The Kiosk template plus class-based deny-by-default enforces "only essential capabilities" at the USB layer. Endpoint groups let you express different "essential" sets per role (e.g. Engineering allows storage from approved vendors; Office allows printers + audio + HID only; Kiosk allows HID only).

Auditor language: "USB device classes are enabled by deliberate allow rule per endpoint group. Default disposition for all groups is deny. Each endpoint is assigned to exactly one group; per-group policy is enforced at the kernel-adjacent class level."

3.4.7 — Restrict nonessential programs and functions

USB connectivity is one such function. The same enforcement covers this control as 3.4.6.

3.5 Identification and Authentication

3.5.1 / 3.5.2 — Identify and authenticate users

Identification + authentication is delegated to Supabase Auth. Email + password is the default mechanism; password complexity follows Supabase's NIST-aligned policy.

3.5.3 — Multifactor authentication for privileged accounts

TOTP MFA is available and can be required tenant-wide via the require_mfa flag. Owner / admin accounts are typically the privileged accounts in scope; enabling tenant-wide enforcement is the recommended posture for environments handling CUI.

Auditor language: "PermitUSB supports TOTP-based multifactor authentication provided by Supabase Auth. The tenant-level require_mfa setting enforces MFA on all dashboard sign-ins. The customer organization enables this setting as part of its authentication policy."

3.6 Incident Response

3.6.2 — Track, document, and report incidents

Tamper events (service-stop attempts, watchdog re-disable, refresh-token replay, policy-stale) are logged to the cloud and routed to email and / or webhook channels per the tenant's alerting configuration. Block events on policies marked sensitive trigger the same alert path.

Auditor language: "PermitUSB classifies four agent-level tamper conditions and emits them as discrete event records that trigger configurable alerts. Alerts route to email, generic JSON webhooks (compatible with Slack / Teams / PagerDuty / SIEM ingest), or both. Incident response procedures should reference the tamper event taxonomy documented at /docs/self-protection."

3.8 Media Protection

3.8.7 — Control the use of removable media on system components

Direct mapping. Removable media is controlled via the PermitUSB policy engine. Every plug / unplug event is logged with full device fingerprint (VID, PID, serial, class, friendly name, vendor manufacturer string).

Auditor language: "Removable media usage on managed endpoints is governed by PermitUSB's per-tenant policy. Default disposition is block; allow rules are explicit, scoped to specific device fingerprints (VID/PID, serial, class, or vendor name). Every device interaction generates an event record retained for 365 days."

3.8.8 — Prohibit use of portable storage devices when such devices have no identifiable owner

Per-device serial-based 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 opt to disallow them explicitly.

Auditor language: "PermitUSB enforces device ownership identification via per-serial allow rules. Devices reporting non-unique or absent serial numbers are surfaced as warnings in the dashboard, enabling administrators to disallow un-identifiable devices in line with the control's intent."

3.13 System and Communications Protection

3.13.1 — Boundary protection

USB is one boundary among many. PermitUSB controls that boundary; pair 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. The cloud surface enforces HSTS. Agent enrollment + token rotation use signed JWTs over the same TLS channel.

3.13.11 — Cryptography for protecting CUI

PermitUSB's agent encrypts the cached refresh-token credential at rest using DPAPI scoped to LocalMachine. Cloud-side data is stored in Supabase Postgres with provider-level at-rest encryption. FIPS validation status of the underlying TLS and storage providers is the responsibility of the customer to confirm with the assessor; PermitUSB itself does not implement custom cryptography.

3.13.13 — Control / monitor use of mobile code

Indirect: by controlling which USB mass storage devices can attach, PermitUSB constrains a common mobile-code delivery vector. The control's full intent (script / binary execution governance) requires endpoint anti-malware / EDR; PermitUSB is complementary, not a replacement.

3.14 System and Information Integrity

3.14.1 — Identify, report, and correct flaws in a timely manner

Tamper events provide the "report" half. The watchdog provides the "correct" half for in-band tampering (re-disabling devices that were re-enabled out-of-band). Operating system patching and PermitUSB agent updates are the customer's responsibility; agent updates are signed MSIs distributed via the dashboard's authenticated download.

3.14.6 — Monitor systems

The agent runs continuous USB-event monitoring on every managed endpoint. Events flow to the cloud within seconds and surface on the dashboard within ~5 seconds of plug-in.

3.14.7 — Identify unauthorized use

Every block event is by definition an "unauthorized use" attempt. Block events are logged to events and, if the matched policy is marked sensitive, fire an immediate alert to the configured channels.

What PermitUSB does not address

PermitUSB is a USB device control product. It does not address — and should not be cited as primary evidence for — the following control families:

• 3.2 Awareness and Training — entirely a customer programme
• 3.7 Maintenance — endpoint maintenance procedures are out of scope
• 3.9 Personnel Security — HR / vetting controls
• 3.10 Physical Protection — site security
• 3.11 Risk Assessment — your security programme owns this
• 3.12 Security Assessment — your assessor / SSP process

Within families PermitUSB partially covers, the following sub-controls are explicitly not addressed and require other tools / processes:

• File-content data loss prevention (DLP)
• BitLocker / disk-encryption enforcement
• Network device control (Ethernet / Wi-Fi / Bluetooth)
• Endpoint anti-malware / EDR
• Vulnerability management / 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 wording PermitUSB-specific that's not on this page, email compliance@permitusb.com. We'll either provide the language directly or update this page so it's available to every customer.