CM.L2-3.4.9 User-Installed Software: Policy and Monitoring

CM.L2-3.4.9 corresponds to requirement 3.4.9 in NIST SP 800-171 Rev 2: control and monitor user-installed software. It is one of the shortest requirements in the standard and one of the easiest to under-document, because the words are simple and the behavior it covers is everywhere. Every time an employee installs a tool, a plugin or a package, this practice applies.

What counts as user-installed software

Software is user-installed when someone other than a managed deployment process puts it on a system. The obvious case is a standard installer run by an employee with local administrator rights. The less obvious cases are portable applications run from a download folder, browser extensions, scripting packages pulled by a developer with a package manager, and applications from an app store. Your policy should say which of these are permitted, which are prohibited and which require approval. NIST SP 800-171 Rev 2 gives examples on both sides: permitted installations include updates and security patches to existing software and applications from organization-approved app stores, and prohibited installations may include software with unknown or suspect pedigrees or software the organization considers potentially malicious.

The three assessment objectives

NIST SP 800-171A states three objectives for this requirement. A policy for controlling the installation of software by users is established. Installation of software by users is controlled based on that policy. Installation of software by users is monitored. The policy is the first piece of evidence, the control mechanism is the second, and the monitoring records are the third. The wording is in NIST SP 800-171A.

Controlling installation

Control is mostly about removing the ability to install without approval. The most effective measures are the ones that need no user discipline.

• Remove local administrator rights from standard user accounts, so installers that need elevation fail.
• Enforce an application execution policy, as described in our CM.L2-3.4.8 guide, so that unapproved binaries do not run even if they are copied into place.
• Offer a managed catalog or deployment tool for approved software, so the easy path is the compliant path.
• Provide a request route for software that is not yet approved, with a defined approval workflow.

Monitoring installation

Monitoring means you can see what was installed and when. Useful sources include endpoint inventory scans that compare installed software with the approved list, endpoint protection alerts on new executables, application control audit logs that show blocked or newly seen binaries, and change records from the deployment tool. The key is a recurring review with a record that it happened. An assessor will want to see not only that logs exist, but that someone looks at them and acts on exceptions.

Developer and engineering workstations

Teams that need compilers, package managers and specialized engineering tools are the hardest case. A blanket ban stops work, and a blanket allowance defeats the control. A workable approach is to approve the toolchain as a defined set, restrict package sources to a managed mirror where possible, and keep a short list of named exceptions with owners and review dates.

Evidence that tends to satisfy the objectives

The CMMC Assessment Guide frames the assessor's questions as whether user controls prohibit unauthorized installation and whether all software in use is approved. Keep the policy document with its approval date, the user rights configuration showing standard users cannot install, the approved software list, the request and approval records for a sample of recent installations, and the output of the most recent inventory comparison. Link these together in your system security plan so an assessor can follow the chain from policy to enforcement to monitoring. The approved software list guide describes what each list entry should contain.

Where DigVel fits

When a user asks for a tool that is not on the approved list, someone has to evaluate it quickly and document the decision. DigVel handles that step as a fixed-scope service: OSINT screening of the vendor, sandbox analysis of the installer and a written report with a recommendation. See the service overview and the methodology. This article is general information, not legal advice or an assessment result.