Controlling user-installed software is a cornerstone requirement of CM.L2-3.4.9 (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2): you must know what's on endpoints and prevent unauthorized applications from running. This post gives a practical, compliance-focused playbook for building an accurate software inventory and an allowlist (whitelist) strategy, including tools, implementation steps, evidence to collect for audits, and examples applicable to small businesses.
Why this control matters (risk and compliance context)
Failing to inventory and restrict user-installed software increases the risk of malware, unpatched apps, shadow IT, and data exfiltration—risks that directly compromise Controlled Unclassified Information (CUI) and violate NIST/CMMC requirements. From a compliance perspective, CM.L2-3.4.9 expects demonstrable processes and technical controls: up-to-date inventories, enforceable allowlists, change/exception workflows, and monitoring/logging that show you actively control software usage on CUI systems.
Step 1 — Build an accurate, authoritative software inventory
Start with discovery: use endpoint management and EDR telemetry (Microsoft Intune/Endpoint Manager, SCCM/ConfigMgr, Jamf for macOS, CrowdStrike, Tanium, or open-source agents) to collect installed package lists, running processes, and publisher metadata. For Linux servers, include package manager outputs (rpm -qa, dpkg -l), and for macOS use system_profiler SPApplicationsDataType. Store results in a centralized CMDB or inventory spreadsheet and normalize entries (name, version, publisher, install path, hash, OS, owner, business justification). Automate weekly scans and reconcile with asset records to detect drift.
Step 2 — Design an allowlist strategy (types, pros/cons, and controls)
Decide your allowlist approach: publisher rules (recommended for Windows) allow signed installers from trusted vendors and scale well; hash rules are highly specific but brittle (every update changes the hash); path rules are easy but can be bypassed. On Windows use AppLocker or Microsoft Defender Application Control (MDAC) with publisher rules and code-signing; on macOS enforce Gatekeeper and use MDM (Jamf, Intune). On Linux consider package-manager enforcement, AppArmor/SELinux policies, and kernel-level signing or IMA/EVM for critical hosts. Remove local admin rights from standard users so installations require an approved change process—this is a foundational compensating control if full allowlisting is phased in.
Example: small consulting firm (50 users) — phased approach
A 50-seat firm can phase implementation: (1) Inventory week 1–2 using Intune agent + an enterprise scan to produce the initial approved-software list; (2) Pilot weeks 3–6 on 10 users with AppLocker/MDAC policies that permit only Microsoft-signed apps and a short approved list (Office, approved dev tools); (3) Enforce-wide: deploy policies via Intune/Group Policy, remove local admin rights, and implement a one-click exception request (ticket in ITSM). Evidence for auditors: inventory exports, AppLocker policy XML, exception tickets, and MDM deployment reports.
Step 3 — Operationalize: change control, monitoring, and exceptions
Create a documented approval workflow: request (business justification), security review (vulnerability check, licensing), testing (sandbox), and formal approval that updates the allowlist (CMDB + AppLocker policy). Log all decisions and retain records. Monitor runtime attempts via EDR and application control logs (AppLocker/MDAC events, Intune compliance reports, Jamf logs). Feed alerts to your SIEM (or a lightweight log aggregator for small firms) and create automated tickets for blocked installs so you can triage potential false positives versus malicious attempts.
Technical tips and evidence collection (practical details)
Prefer publisher rules over hashes for Windows AppLocker; generate policy XML using New-AppLockerPolicy (PowerShell) from a reference machine and refine in audit mode before enforcement. For MDAC, use Intune Endpoint Security → Application control to deploy policies. On macOS gatekeep enforcement should be combined with MDM profiles restricting kernel extension approvals and preventing bypass. Maintain a signed, version-controlled allowlist repository (Git) and include: CSV of approved apps, policy XMLs, MDM configuration snapshots, screenshots of deployment status, and sample logs showing blocked executions. Note: hash rules require a process to update hashes with every app update—automate hash regeneration and testing in your CI/CD or IT packaging workflow.
Compliance tips and best practices
Map artifacts directly to CM.L2-3.4.9 in your policy documentation and evidence package: initial inventory report, allowlist policy files, deployment change tickets, exception approvals, and monitoring/alert history. Keep exception windows short and require re-evaluation if an exception remains more than 90 days. Use least-privilege (remove admin rights), sandbox/VDI for high-risk user needs, and network controls (proxy, DNS filtering, block known software distribution sites) as compensating controls during rollout. Regularly (quarterly) reconcile inventory against the CMDB and perform a tabletop to validate response to a blocked-install alert.
In summary, meeting CM.L2-3.4.9 requires a repeatable program: accurate discovery and inventory, a technically enforceable allowlist tailored to your OS mix, documented exception/change control workflows, and continuous monitoring with retained evidence. For small businesses the path is phased: inventory, pilot allowlisting, remove admin rights, automate, and then enforce—each step provides tangible security improvements and audit evidence to demonstrate compliance.
