What "Best Practices" Actually Means Under CMMC
The phrase "best practices" gets used loosely in cybersecurity. In the context of CUI protection under CMMC, it has a specific meaning: the controls and configurations that, when implemented correctly, satisfy the 110 requirements of NIST SP 800-171 and hold up under a C3PAO assessment. These are not aspirational guidelines. They are the floor.
The SPRS scoring system makes the stakes concrete. Every unmet requirement subtracts points from a scale that runs from -203 to 110. High-criticality requirements are worth 5 points each; failing a cluster of them pushes a score deep into negative territory before you've even touched access control or encryption. Primes and DoD contracting officers now review SPRS scores before awarding task orders. A score below zero is a flag. A score below -50 can remove a contractor from consideration entirely.
This guide covers four domains that collectively account for 56 NIST SP 800-171 requirements and 148 SPRS points: Access Control (AC), System and Communications Protection (SC), Configuration Management (CM), and Audit and Accountability (AU). The controls in these domains govern how CUI is accessed, how it moves across networks, how the systems that hold it are configured, and whether you have the logs to prove any of it. Get these right and you've handled the bulk of what assessors spend their time on.
Access Control: Who Gets In and What They Can Do
Access control is the largest domain in CMMC Level 2. Twenty-two requirements govern who can reach CUI systems, under what conditions, and with what permissions. Failures here are the most common findings in C3PAO assessments, and the most damaging to SPRS scores.
The foundational principle is least privilege. Every user account should have access to exactly what that person needs to do their job, nothing more. On a practical level, that means standard users cannot install software, change security settings, or browse file shares outside their project scope. Administrators use a separate privileged account only when they are performing administrative tasks. Using an admin account as a daily driver is a finding under AC.L2-3.1.5 and AC.L2-3.1.6, both of which carry SPRS weight.
Shared accounts are a hard stop. When multiple people log in under the same credential, you lose the ability to trace actions to an individual user. Assessors will request your account list and look for shared logins, generic service accounts with interactive access, and former employees whose accounts haven't been disabled. Provisioning and deprovisioning procedures need to be documented and demonstrable.
| Multi-factor authentication | Required for all remote access to CUI systems and for privileged account logins. MFA must be active, not just configured. Assessors will test it. Hardware tokens, authenticator apps, and smart cards all satisfy the requirement. SMS-based codes are acceptable but not preferred given SIM-swapping risks. |
| Session controls | Systems must lock after a defined period of inactivity. AC.L2-3.1.10 requires session lock for remote access sessions. The specific timeout threshold is not prescribed, but 15 minutes is the common implementation. Configure it, document it in your SSP, and make sure it's enforced at the group policy or MDM level — not just as a user preference. |
| Failed logon limits | AC.L2-3.1.8 requires that unsuccessful logon attempts be limited. Typical implementations lock an account after 3 to 5 failed attempts. The lockout threshold and duration must be documented. Indefinite lockouts require administrator intervention to unlock; time-based lockouts (15 or 30 minutes) are also compliant. |
| Remote access | Every remote connection to a CUI system must go through an encrypted, authenticated path. VPN is the standard. Split tunneling must be disabled or controlled — if a remote user can simultaneously connect to the CUI environment and an untrusted external network, that's a gap under AC.L2-3.1.14. Document your remote access policy and configuration in your SSP. |
| CUI flow control | AC.L2-3.1.3 requires that CUI flow according to approved authorizations. In practice, this means data loss prevention (DLP) controls, restrictions on copying CUI to personal cloud storage or USB drives, and documented procedures for approved transfer methods. If a standard user can email CUI to a personal Gmail account with no technical barrier, that's a finding. |
Network and Boundary Protection: Keeping CUI Contained
The System and Communications Protection domain covers how your network is structured, how CUI moves across it, and what happens at the boundaries where your environment meets the outside world. Sixteen requirements, 42 SPRS points. Most of the weight sits on architectural decisions you make once and then maintain.
The CUI boundary is the starting point. Every system that stores, processes, or transmits CUI is in scope for your CMMC assessment. That boundary must be defined in your System Security Plan with enough precision that an assessor can verify what's in scope and what isn't. Vague boundary descriptions ("our office network") are a common SSP deficiency. A network diagram showing the CUI segment, its connections to other networks, and the controls at each boundary is what assessors expect to see.
| Network segmentation | CUI systems should be isolated from general-purpose networks using VLANs, subnets, or physical separation. A flat network where the engineering workstation with export-controlled drawings sits on the same segment as the front desk computer and the guest WiFi is not a compliant architecture. The separation doesn't need to be physically elaborate, but it needs to be real, documented, and enforced at the firewall or switch level. |
| Deny-by-default firewall policy | SC.L2-3.13.6 requires a deny-all, permit-by-exception posture. Every rule in your firewall that allows traffic into or out of the CUI segment must have a documented business justification. Assessors will request firewall rule exports. Rules with descriptions like "temp" or "test" from three years ago are findings. Review your ruleset, document each rule, and remove anything that doesn't have a current justification. |
| Encryption in transit | CUI must be encrypted when transmitted over open or untrusted networks. TLS 1.2 or higher is required for all web-based access to CUI. VPN connections must use strong encryption (AES-128 minimum; AES-256 preferred). Email containing CUI must transit through a FedRAMP Moderate-authorized platform. Standard Microsoft 365 or Gmail does not qualify. Microsoft 365 GCC does. |
| Wireless access | If wireless networks are used in the CUI environment, they must be separated from general or guest wireless networks, use WPA3 or WPA2-Enterprise authentication, and be documented in the SSP. Guest wireless networks must never bridge to the CUI segment. Many small contractors meet this requirement by prohibiting wireless access to CUI systems entirely and documenting that prohibition. |
| Public-facing systems | SC.L2-3.13.5 requires that publicly accessible system components be physically or logically separated from internal networks. If your organization runs a public website or customer-facing portal, the server hosting it must not sit on the same network as your CUI systems. DMZ architecture or cloud-hosted public systems with no direct path to the CUI environment both satisfy this requirement. |
System Configuration: Hardened Baselines and Change Control
Configuration Management is nine requirements and 33 SPRS points. The core obligation is straightforward: know what your systems are running, configure them securely, and control what changes. In practice, many contractors have never formally documented their configurations and have no change control process at all. That's a clean sweep of CM findings.
A baseline configuration is a documented, approved snapshot of how a system is configured. It covers the operating system version, installed software, enabled services, network settings, and security configuration. The baseline for a Windows workstation in the CUI environment might reference the CIS Benchmark for Windows 10 or DISA STIG settings. The specific hardening framework matters less than having one, documenting it, and being able to show that your systems match it.
| Baseline configurations | CM.L2-3.4.1 requires an established and maintained baseline configuration for every system in the CUI boundary. The baseline must be documented in a format assessors can examine. A spreadsheet listing OS version, installed software, and key security settings is a minimum. A configuration management database (CMDB) or automated endpoint management tool (SCCM, Jamf, Ansible) provides a stronger posture and makes compliance evidence easier to produce. |
| Security configuration enforcement | CM.L2-3.4.2 requires that security configuration settings be established and enforced. This is not just documenting what the settings should be — it's verifying they are actually applied. Group Policy or MDM enforcement is the standard mechanism for Windows environments. Assessors may ask you to demonstrate that a deviation from the baseline would be detected or blocked. |
| Least functionality | CM.L2-3.4.6 and CM.L2-3.4.7 require that systems operate with only the capabilities and services needed for their function. Disable services that aren't used. Remove software that isn't needed. A default Windows installation with all features enabled and legacy protocols active is not a compliant baseline. Document what has been disabled and why. Assessors will run service enumeration on systems to verify. |
| Change control | Changes to CUI systems must go through a documented change control process. This doesn't require enterprise ITSM tooling. A documented procedure, a log of changes with dates and approvals, and evidence that changes are reviewed against the baseline all satisfy the requirement. The process must be defined before an assessment, not assembled during one. |
| Software whitelisting | CM.L2-3.4.8 requires controlling which programs execute on CUI systems. Application whitelisting (Windows Defender Application Control, AppLocker, or equivalent) blocks unauthorized software from running. This is one of the more operationally demanding CM requirements for small organizations, but it's also one of the most effective controls against malware. At minimum, document a policy prohibiting unauthorized software and pair it with endpoint protection that can detect and block unknown executables. |
Audit and Logging: Proving Controls Are Working
The Audit and Accountability domain is where best practices become provable. Nine requirements and 19 SPRS points govern what you log, how long you keep it, and whether you actually review it. For a C3PAO assessor, the logs are the evidence. A control you've configured but can't demonstrate through logs is a control you may not get credit for.
Logging must cover every system in the CUI boundary. Windows event logs, Active Directory authentication events, firewall logs, VPN connection logs, and file server access logs are all expected sources. If CUI systems are in scope and not sending logs anywhere, that's a direct finding under AU.L2-3.3.1. That requirement carries 5 SPRS points and cannot be deferred to a POA&M.
| Log sources | Every CUI-boundary system must have logging enabled and those logs must be retained. At minimum: Windows Security Event Log (authentication, privilege use, policy changes), Active Directory (logon events, account management), firewalls (accepted and denied connections at the CUI boundary), VPN (connection and disconnection events), and file servers (access to folders containing CUI). Cloud services in scope must have audit logging enabled in their admin console. |
| Retention | The NIST standard does not specify a retention period by number. C3PAO assessors expect a minimum of 90 days of readily accessible logs. This aligns with DFARS 252.204-7012 incident reporting, which requires 90 days of forensic preservation after a reportable incident. Document your retention period in the SSP and make sure your logging infrastructure enforces it. Assessors will ask you to pull logs from 60 to 90 days ago on the spot. |
| Log protection | AU.L2-3.3.2 requires that audit information and tools be protected from unauthorized access, modification, and deletion. Logs should be stored on a system separate from the systems generating them. Standard users must not have write or delete access to log storage. A centralized log management platform or SIEM with access controls and integrity checking satisfies this requirement. Logs stored only on the originating system can be manipulated by a compromised account. |
| Review | Logging without review doesn't satisfy the AU domain. AU.L2-3.3.5 requires that audit records be reviewed and reported. This means a defined review cadence (daily, weekly), documented evidence that reviews occurred, and a process for escalating anomalies. Automated alerting from a SIEM or log management tool supports this requirement significantly. If reviews happen informally with no record, assessors have nothing to examine. |
| User traceability | AU.L2-3.3.2 requires that actions be traceable to individual users. Shared accounts break this. If ten people use a shared "admin" login, you cannot determine which individual took a given action from the logs. Every user must have a unique account, and log events must capture that identity. IP-address-only logging is not sufficient when multiple users share a workstation or NAT address. |
How 1TEN Supports CUI Protection Across All Four Domains
Implementing and maintaining these controls across AC, SC, CM, and AU is a continuous operational commitment, not a one-time project. 1TEN is an air-gapped compliance platform built specifically for defense contractors handling CUI. It tracks all 110 NIST SP 800-171 requirements, maintains your asset inventory and CUI boundary documentation, generates your System Security Plan, and produces the evidence packages a C3PAO assessor needs to verify each control. Everything runs on a dedicated appliance inside your environment. No CUI leaves your network.
For the four domains covered in this guide, 1TEN provides structured modules for access control documentation, configuration baseline tracking, audit log management, and network boundary scoping. When a control changes, the SSP updates. When an assessor asks for evidence, it's in one place. The platform is priced per organization, not per user, which means it scales from a 10-person shop to a 500-person prime without changing the cost model.
Frequently Asked Questions
The most frequently cited findings are shared user accounts, missing multi-factor authentication on remote access, CUI stored in non-FedRAMP-authorized cloud services, absent or incomplete audit logging, and no documented baseline configuration for CUI systems. These are not obscure edge cases. They are the controls assessors check first because they represent the highest-frequency failures across the DIB.
Yes. If a subcontractor receives, stores, processes, or transmits CUI as part of their work on a DoD contract, they carry the same NIST SP 800-171 obligations as the prime. The prime contractor is responsible for flowing down DFARS 252.204-7012 requirements to any subcontractor that handles CUI. Subcontractors handling CUI are subject to the same CMMC certification requirements as primes when those requirements are included in the contract.
Least privilege means every user account has access only to the systems, folders, and functions required for their specific job. On CUI systems, this means standard users cannot install software, modify security settings, or access data outside their project scope. Administrators use a separate privileged account only when administrative functions are actually needed, not as their daily login. Assessors will request a list of privileged accounts and verify that each one has a documented business justification.
A compliant CUI boundary separates systems that handle CUI from general-purpose networks using VLANs or physical segmentation. The boundary is defined in your System Security Plan with enough precision that an assessor can verify what is in scope. Firewall rules follow a deny-by-default policy: only explicitly authorized traffic passes between the CUI segment and other networks. Remote access to CUI systems requires VPN with MFA. Wireless access to CUI systems is either prohibited or enforced through a separate, access-controlled SSID.
NIST SP 800-171 does not specify a precise retention period, but the standard expectation in C3PAO assessments is a minimum of 90 days of readily accessible logs. This aligns with the DFARS 252.204-7012 incident reporting requirement, which mandates 90-day forensic preservation following a reportable cyber incident. Many organizations retain logs for 12 months to support broader audit and investigation needs. Whatever retention period you document in your SSP, you must be able to produce logs from that full window on demand.
Only if the cloud service holds a FedRAMP Moderate (or higher) authorization. Standard commercial offerings — Microsoft 365, Google Workspace, Box, Dropbox, OneDrive — do not qualify. Compliant options include Microsoft 365 GCC, Google Workspace for Government, and other specifically FedRAMP Moderate-authorized platforms. This applies to email, file storage, collaboration tools, and any other cloud service that touches CUI.