User-installed Software CM-11

Configuration Management · Low baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds CM-11 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, Configuration Management family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

CM-11 (User-installed Software) is about controlling what software people are allowed to install on a system themselves. You set a policy for what users may install, enforce that policy with real technical controls, and check compliance on a schedule. It is a Configuration Management control that sits in the Low baseline, and it keeps unvetted or risky software off the machine.

What good looks like

Write the policy first: say what software users may install themselves — usually none — and that only administrators add packages, from approved sources.
Restrict who can install: only administrators, through sudo, may run the package manager; normal users cannot write to system paths.
Enforce with real controls, not just words — package-manager permissions, a limited set of repositories, or an allowlist.
Baseline the installed software so anything added later stands out.
Monitor compliance on a set frequency — compare what is installed now against what the policy allows, and remove or flag the rest.

Framework mapping

NIST CSF 2.0 — PR.PS-01 — Configuration management practices are established and applied
CIS Controls v8 — Control 2 — Inventory and Control of Software Assets

How to move it toward Implemented

Write a one-page software policy: users may not install packages, only administrators via sudo may run apt or dnf, and only from approved repositories.
Confirm the restriction actually holds — check /etc/sudoers (edit with visudo) so normal users have no package-manager rights and cannot write to system directories.
Capture a baseline package list to a dated file (dpkg-query -W on Debian/Ubuntu, or rpm -qa on Red Hat/Fedora) so later installs are easy to spot.
Run a monthly check that diffs the current package list against the baseline, review any additions, and save the result as a dated log file.
Attach that dated review log as hardening evidence on the asset, naming CM-11 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.