CM-11: User-installed Software

CM-11 requires you to establish and enforce organization-defined rules that govern whether, how, and under what approvals users can install software. To operationalize it fast, decide your default stance (block-by-default or allow-with-controls), implement technical enforcement (least privilege, application control, MDM), and retain evidence that installations are authorized, logged, and reviewed. ¹

Key takeaways:

• Write a clear “user-installed software” standard: what’s allowed, how it’s approved, and what’s blocked. ¹
• Back the policy with technical enforcement: remove local admin, control installers, and monitor install events across endpoints/servers. ¹
• Keep assessor-ready evidence: approvals, exception records, app inventory deltas, and periodic review outputs tied to CM-11. ¹

CM-11: User-installed Software is a “make it concrete” control. Assessors don’t want a general acceptable use policy that vaguely says users “shouldn’t install risky apps.” They want explicit governance for software installation by users, plus operational proof that the rules are followed in production. The practical intent is to reduce malware and license risk, prevent unvetted tools from entering the environment, and keep your configuration baseline from drifting.

This requirement shows up as an audit pain point because it crosses teams: endpoint engineering owns device controls, security operations owns detection and response, IT service management owns request/approval workflows, and compliance owns the narrative and evidence. If you don’t force alignment, you end up with a good policy and weak enforcement, or strong tooling without documented rules and approvals.

This page gives you requirement-level implementation guidance you can put in place quickly: what to decide, what to configure, what to document, and what evidence to retain so you can pass an assessment and reduce real operational risk tied to unmanaged software installation. ²

Regulatory text

Control requirement (excerpt): “Establish {{ insert: param, cm-11_odp.01 }} governing the installation of software by users;” ¹

What the operator must do

You must define and publish organization-specific rules (the “organization-defined parameter”) that govern user-driven software installation. In practice, that means:

• Define who can install software (by role, device type, system boundary, and environment).
• Define what can be installed (approved software list / categories; prohibited software; sources allowed).
• Define how it is approved (ticketing workflow, required review steps, and emergency path).
• Define how it is enforced and monitored (technical controls, logging, periodic reviews).
• Define exceptions (who grants, time limits, compensating controls, and revocation). ¹

Plain-English interpretation (cm-11: user-installed software requirement)

Users should not be able to introduce new software into your environment without guardrails. CM-11 expects you to set those guardrails in writing, implement them in tooling and process, and prove you follow them.

A workable interpretation for most regulated environments:

• Default deny user installs on managed endpoints and servers.
• Allow by exception through a documented approval process for business-justified software.
• Allow self-service only for a controlled catalog (managed app store) that IT/Sec can monitor and revoke.

Who it applies to (entity and operational context)

CM-11 applies to organizations operating federal information systems and contractor systems handling federal data. ¹

Operationally, scope it to:

• Managed endpoints (workstations, laptops, VDI, mobile devices where apps can be installed).
• Servers (where “user install” may mean admins or developers installing packages).
• Privileged user populations (developers, data scientists, engineers) who frequently request tools.
• Remote workforce and BYOD scenarios, if within your system boundary (clarify boundary in your SSP/control narrative). ²

What you actually need to do (step-by-step)

1) Set your governing rule set (the “ODP”)

Make four decisions and write them into a short standard (one to three pages):

1. Default stance: Block user-installed software unless explicitly allowed, or allow only from managed catalogs.
2. Approval authority: Identify who can approve (IT, Security, AppSec, Data Governance) by software type.
3. Permitted sources: Examples include managed app stores, signed packages from approved repositories, or software pushed by endpoint management.
4. Exception controls: Time-bound exceptions, business justification, compensating controls (EDR required, network restrictions, no sensitive data access).

Deliverable: “User-installed Software Standard (CM-11)” mapped to your access and endpoint policies. ¹

2) Tie CM-11 to a control owner and operating procedure

Assign a single accountable owner (often Endpoint Engineering or IT Operations) with Security as a required approver for certain classes of software. Then document an operating procedure:

• Intake request method (ticket form fields).
• Review steps (license, security, data access).
• Implementation steps (push software via MDM/endpoint tooling).
• Post-install validation (inventory update, logging check).

If you use Daydream for GRC, create a CM-11 control record that links: owner, procedure, review cadence, and the evidence list below so collection is repeatable and assessor-ready. ¹

3) Implement technical enforcement (minimum viable set)

Your evidence needs to show the rule isn’t optional. Prioritize controls that prevent silent installs and create audit trails:

• Least privilege: Remove local admin from standard users; tightly manage privileged accounts.
• Application control: Allowlisting for installers/binaries where feasible; block known prohibited categories.
• Endpoint management: Managed app deployment (software center / enterprise app catalog).
• Logging: Centralize install-related events (endpoint logs, EDR telemetry) to your SIEM or log platform.
• Detection: Alerts for unauthorized installs, new executables in sensitive paths, or unknown publishers.

For servers and engineering environments, include package manager governance (approved repos, signed artifacts, change control for new packages). ²

4) Build the “approved software” path users will accept

A CM-11 program fails when users have no reasonable way to get tools they need. Provide:

• A standard catalog of common apps (browsers, PDF tools, conferencing, IDEs if allowed).
• A fast approval lane for low-risk software (clear criteria).
• A security review lane for higher-risk software (network tools, remote access tools, password managers, crypto miners, unapproved AI clients).

Write the criteria so your help desk can route requests without guessing.

5) Run a periodic review that produces artifacts

Pick a review cycle that fits your environment (you define it). The review should answer:

• What software was installed since the last review?
• Which installs were user-initiated vs IT-pushed?
• Were they authorized?
• Are exceptions still valid?

Output: a dated report or ticket set, plus remediation actions for unauthorized software.

Required evidence and artifacts to retain

Keep artifacts that prove governance exists and operations match governance:

Governance artifacts

• User-installed Software Standard (CM-11) with version history and approval.
• RACI or control ownership record (owner, approvers, operators).
• Exception process definition and approval matrix.

Operational artifacts

• Access control evidence: proof standard users lack install permissions (role config, endpoint policy screenshots/exports).
• Application control/MDM configurations (exports or screenshots showing allowlist/blocked installers).
• Approved software catalog (current list + change log).
• Sample tickets for install requests showing approval, justification, and fulfillment method.
• Exception register (request, approver, scope, expiration, compensating controls).
• Software inventory reports (before/after deltas) and periodic review outputs.
• SIEM/EDR alert samples for unauthorized install attempts and follow-up tickets.

A common audit hangup: policies without proof of enforcement, or logs without a written standard tying them to CM-11. ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Can a standard user install software on a managed laptop? Show me.”
• “How do you define ‘user-installed’ vs IT-installed? Where is that written?”
• “Show three examples of non-standard software requests and the approvals.”
• “How do you detect unauthorized installs, and what happens next?”
• “How do you control installs for developers/admins who legitimately need tools?”
• “How do you ensure exceptions expire and are reviewed?”

Hangup patterns:

• The approval workflow exists, but endpoints still allow local installs.
• The org blocks installs, but engineers bypass through portable executables or unmanaged environments without detection.
• The approved catalog exists, but no one reviews drift between inventory and approvals.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
“Policy-only” CM-11	Assessors look for enforcement and evidence	Pair the standard with endpoint controls and logged events.
Local admin by convenience	Users can install anything, silently	Use privileged access workflows; separate admin accounts; constrain elevation paths.
No exception lifecycle	Exceptions become permanent	Add expiration dates and a review trigger; revoke by default on expiry.
Approved list without change control	The list drifts and becomes meaningless	Require tickets to add/remove items; keep a change log.
Ignoring servers/dev tooling	Risk moves to build systems and admin hosts	Apply the same governance to package repos and privileged installs.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this control, so you should treat CM-11 primarily as an assessment readiness and risk-reduction requirement rather than a “case law” driven one.

Operational risk is straightforward:

• Uncontrolled installs increase malware and remote access tool exposure.
• Unvetted software can create data egress paths and shadow IT.
• Inventory drift complicates incident response and vulnerability management because you cannot quickly answer “where is this software installed?” ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Name the CM-11 control owner and approvers; document the RACI.
• Publish the CM-11 User-installed Software Standard (keep it short and enforceable). ¹
• Identify your current install paths: local admin, software center, package managers, unmanaged devices.
• Start an exception register immediately, even if it’s a spreadsheet, so you can show governance in motion.

Days 31–60 (enforce and create the happy path)

• Remove local admin from standard users where feasible; document any scoped exceptions.
• Stand up or refine an enterprise software catalog and ticket workflow with required fields (business need, data access, publisher, license).
• Configure logging/EDR detections for install events and unauthorized binaries in sensitive locations.
• Run your first software inventory drift review; generate a remediation list.

Days 61–90 (prove operation and harden)

• Perform a second review cycle and show closure on findings (uninstall, approve retroactively with justification, or isolate).
• Tighten application control rules for high-risk categories and prohibited software.
• Train IT service desk and engineering leads on request routing and exception discipline.
• In Daydream, map CM-11 to the owner, procedure, and recurring evidence artifacts so evidence collection is repeatable for audits. ¹

Frequently Asked Questions

Does CM-11 require a full application allowlist program?

CM-11 requires governance over user-installed software, not a specific technology. An allowlist is a strong enforcement method, but you can also meet intent with least privilege, managed app deployment, and monitoring that proves unauthorized installs are blocked or remediated. ¹

Can we allow self-service installs from an enterprise app store?

Yes, if your rules state that self-service is limited to a controlled catalog and you can show the catalog is curated, logged, and reviewed. Treat catalog additions as a change-controlled event with security input for higher-risk apps. ²

How do we handle developers who need frequent tools and packages?

Define a separate “engineering software” lane with approved repositories, signed packages where possible, and time-bound exceptions for niche tools. Keep evidence that requests were approved and that installs occurred through controlled mechanisms. ¹

What counts as “user-installed software” in practice?

Include any software a user initiates or introduces outside your standard managed deployment path: installers, portable executables, browser extensions (if in scope), and packages installed via language/package managers on managed systems. Write your definition in the CM-11 standard so audits don’t turn into semantics. ¹

If we block installs, what evidence should we show an auditor?

Show the written standard, endpoint/MDM configuration that enforces it, and logs or reports demonstrating install attempts are prevented or detected. Add a sample of exception approvals and periodic review outputs to prove ongoing operation. ¹

How do third-party provided software agents (monitoring, remote support) fit CM-11?

Treat third-party agents as software installations that must follow your governed path: documented approval, controlled deployment, and inventory visibility. If a third party installs directly, require it contractually and operationally to go through your change/approval process and provide installation records. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5