CMMC NUGGET #19

Level 2 Baseline Controls

AC.L2-3.1.21: Limit use of portable storage devices on external systems

This is the external-facing cousin of MP.L2-3.8.7 (Nugget #17), which controls removable media on your own systems. This control addresses the reverse scenario: your organization’s data on portable storage connecting to systems outside your control. Endpoint security policies restricting or monitoring USB use on external systems, or issuing centrally managed encrypted USB drives for authorized off-network use, are standard approaches.

AU.L2-3.3.9: Limit management of audit logging functionality

Nugget #8 covered eight of the nine AU controls; this is the one that got left out of that lineup. It requires restricting who can modify audit log settings, because an attacker (or a careless insider) who can alter logging configuration can also cover their tracks. Role-based access limiting log management to designated administrators, not general IT staff, is the expected implementation.

CM.L2-3.4.1: Establish and maintain baseline configurations and inventories

Configuration management tools maintaining a current baseline of hardware, software, firmware, and documentation, updated as the environment changes, not built once and forgotten.

CM.L2-3.4.2: Establish and enforce security configuration settings

Standardized security settings enforced across your IT footprint, with automated tools flagging and remediating drift from baseline.

CM.L2-3.4.6: Employ the principle of least functionality

Disable or remove features, services, and applications that aren’t essential to business operations. Fewer moving parts, fewer things that can go wrong.

CM.L2-3.4.7: Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services

This control covers more than software. It also reaches functions, ports, and protocols, disabling unused services like FTP or Bluetooth, closing ports that serve no business purpose, and restricting protocols the organization has no operational need for. A documented inventory of what is actually essential is the starting point for deciding what is allowed.

CM.L2-3.4.8: Apply deny-by-exception or permit-by-exception policy

This is where software execution gets locked down specifically. Organizations can choose either approach: deny-by-exception (blacklisting), where software runs by default unless it’s on a list of blocked programs, or the stronger deny-all, permit-by-exception (whitelisting), where nothing runs unless it’s explicitly authorized. Either satisfies the requirement, but whitelisting is generally regarded as the more effective control.

IA.L2-3.5.10: Store and transmit only cryptographically-protected passwords

Here’s where the junk drawer has a mislabeled item worth fixing. Passwords should be protected with a one-way cryptographic hash function, bcrypt, scrypt, or PBKDF2 with proper salting, not reversible encryption like AES. Encrypting a password with AES means it can be decrypted, which defeats the entire purpose of secure password storage. For transmission, TLS remains the correct answer. Storage and transmission are two different problems with two different tools; don’t reach for the same one for both.

IA.L2-3.5.11: Obscure feedback of authentication information

Generic error messages during login attempts. “Invalid username or password” tells an attacker nothing useful; “that username doesn’t exist” tells them plenty.

IA.L2-3.5.4: Employ replay-resistant authentication mechanisms

This works alongside MFA (IA.L2-3.5.3, covered in Nugget #10) and is often assessed in the same conversation. Time-based codes (TOTP), challenge-response protocols (HOTP), and FIDO2/WebAuthn with hardware security keys are all accepted implementations. No single standard is required or preferred in assessment guidance; any mechanism that prevents captured authentication data from being reused satisfies this requirement.

SC.L2-3.13.3: Separate user functionality from system management

RBAC keeping administrative privileges with designated administrators, with standard users unable to reach system management functions regardless of their general access level.

SC.L2-3.13.4: Prevent unauthorized information transfer via shared system resources

This control is about object reuse and residual information protection, not data flow monitoring. When a shared resource like memory, cache, or disk space is released by one process and reused by another, no residual data from the prior user or process should be recoverable. Processor-level exploits like Meltdown and Spectre are a modern illustration of what happens when this isolation fails at the hardware level. Most current operating systems handle this natively, so the practical work is verifying your OS is a certified, currently supported version and that virtualized or multi-tenant environments (shared hosting, some VDI setups) enforce the same isolation between sessions. Controlling where CUI itself is allowed to flow is a separate concern addressed under Access Control.

SC.L2-3.13.9: Terminate network connections after a defined period of inactivity

Idle connections automatically closed after a set threshold. Simple, frequently under-configured, and an easy win once you define the threshold and actually enforce it.

SC.L2-3.13.12: Prohibit remote activation of collaborative computing devices

Time to correct a genuinely dangerous mix-up. This control is not about Wake-on-LAN or network wake capabilities. It’s about cameras, microphones, and video conferencing systems, devices that could be remotely activated to surveil a room without anyone present knowing about it. The requirement is twofold: prevent remote activation, and provide a clear physical indicator (a light, an on-screen notice) when the device is in use so anyone present can tell. An organization that locked down Wake-on-LAN and called this control satisfied would have a direct, unmitigated finding, because they addressed a completely different risk.

SC.L2-3.13.13: Control and monitor the use of mobile code

Application whitelisting or sandboxing for code executing in browsers and applications. Worth noting the examples have aged: ActiveX is largely extinct. Today’s relevant mobile code risks are things like malicious browser extensions, WebAssembly, and script-based delivery mechanisms embedded in web content.

SC.L2-3.13.14: Control and monitor the use of VoIP technologies

Network segmentation isolating VoIP traffic, encrypted voice communications (SRTP), and regularly patched VoIP infrastructure.

AC.L2-3.1.21 Portable storage restrictions exist in policy only, not technically enforced on external-facing systems
AU.L2-3.3.9 Audit log configuration access not restricted to designated administrators
CM.L2-3.4.1 Baseline inventory built once and never updated as the environment changes
CM.L2-3.4.6 Unnecessary services still running because no one revisited the baseline after initial setup
IA.L2-3.5.10 Passwords encrypted (reversible) instead of hashed (one-way)
SC.L2-3.13.9 Idle timeout configured too long to meaningfully reduce risk, or not configured at all
SC.L2-3.13.12 Wake-on-LAN disabled and mistakenly treated as satisfying this control, cameras and mics never addressed

These sixteen controls span five families and belong in their respective SSP sections, not lumped together under one “baseline controls” heading just because this nugget grouped them together. AC.L2-3.1.21 goes under Access Control, AU.L2-3.3.9 under Audit and Accountability (alongside the eight controls from Nugget #8), CM controls under Configuration Management, IA controls under Identification and Authentication, and SC controls under System and Communications Protection.

For each control your SSP should document:

• The specific technical implementation and configuration
• The policy governing it, including any defined thresholds or review periods
• Who is responsible for implementation and ongoing management
• How compliance is verified and how often

The junk drawer earns its keep. It’s not glamorous, but an assessor will absolutely open it, so it’s worth spending a few minutes here before your next review instead of during it. Questions on any of these sixteen? Contact DTC’s C3PAO team.