CM-11(2): Software Installation with Privileged Status

CM-11(2) requires you to block end users from installing software unless they have explicit, approved privileged status. Operationally, that means standard users cannot run installers, bypass application controls, or self-elevate; installations must flow through controlled admin paths with logging, approval, and periodic review. ¹

Key takeaways:

• Remove local admin rights from standard users and tightly scope privileged roles to software installation tasks. ¹
• Enforce installation through technical controls (application allowlisting, endpoint management, privilege management) and keep auditable logs. ¹
• Prove the control works with role definitions, configuration baselines, exception approvals, and install/event evidence. ¹

“User-installed software” is a common entry point for malware, unlicensed tools, and data-handling gaps because it bypasses security review and configuration management. CM-11(2) closes that path by requiring explicit privileged status for software installation, so installation becomes an administrative act you can govern, log, and audit. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize CM-11(2) is to treat it as an access control problem with a configuration management wrapper: define who can install software, enforce it in endpoints and servers, create a standard request-and-approve workflow, and capture evidence that installations are performed only by privileged identities. ²

This page is written for operators who need to implement and defend the cm-11(2): software installation with privileged status requirement during audits or assessments. You’ll get a plain-English interpretation, a step-by-step implementation approach, the artifacts to retain, common audit hangups, and a practical execution plan that you can assign to control owners and track to completion. ¹

Regulatory text

Requirement (excerpt): “Allow user installation of software only with explicit privileged status.” ¹

What the operator must do:

• Ensure software installation is technically restricted so that only users operating with explicitly granted privileged status can install software. ¹
• Make “privileged status” a deliberate, controlled condition (role membership, just-in-time elevation, or managed admin account) rather than a default attribute of normal user accounts. ²

Plain-English interpretation (what CM-11(2) really means)

CM-11(2) means: no self-service software installs from standard user accounts. If someone wants software installed, they either (a) submit a request and an admin installs it, or (b) receives time-bound privileged elevation through an approved mechanism, with logging and oversight. ¹

Key clarifications that matter in audits:

• “Explicit privileged status” implies you can point to a defined authorization decision (role assignment, privileged access policy, ticket/approval, or JIT elevation record). ²
• “Installation” includes traditional installers, package managers, browser extensions (where enterprise-managed), scripts that drop executables, and anything that introduces new executable code. Your scope should match how software lands in your environment. ²

Who it applies to (entity and operational context)

Entity scope:

• Federal information systems and contractor systems handling federal data commonly implement NIST SP 800-53 controls, including CM-11(2). ²

Operational scope (where it shows up in real life):

• Corporate endpoints (Windows/macOS/Linux laptops and desktops) where users frequently attempt installs.
• Servers and cloud workloads where engineers might install packages directly.
• VDI, jump hosts, and privileged workstations.
• BYOD is tricky: if you allow access to controlled data from unmanaged devices, you need compensating controls because CM-11(2) is hard to enforce without device management. ²

Third-party angle:
If third parties administer your systems (MSP, consultants, developers), their admin actions must also follow the same privileged-install rules: named privileged accounts, approvals where required, and logs retained. Treat them as privileged users, not “external exceptions.” ²

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

Use this as an implementation runbook. Assign an IT control owner for endpoint controls and an IAM/PAM owner for privileged status governance; GRC owns the requirement mapping and evidence cadence. ²

Step 1: Define “privileged status” for installations

Write a short standard that answers:

• Which roles can install software (Endpoint Admins, Server Admins, DevOps Break-Glass, etc.).
• Whether privilege is standing (permanent role) or just-in-time (time-bound elevation).
• What approvals are required (manager + security for high-risk software; IT only for standard packages).
• What logs must be captured and where they are retained. ²

Deliverable: Software Installation Privilege Standard (one to two pages) mapped to CM-11(2). ¹

Step 2: Remove install rights from standard users

Technical goal: a normal user cannot install software system-wide.

Common approaches (choose what fits your stack):

• Remove local administrator membership for users by default; create separate admin accounts for authorized admins.
• Enforce endpoint configuration baselines that prevent installer execution without admin authorization.
• Restrict package manager usage on servers to admin paths only. ²

Deliverable: Baseline configuration (MDM/GPO/config-as-code) showing standard users lack install rights. ²

Step 3: Centralize installation through managed channels

Auditors will ask, “If users can’t install, how do they get tools to do their jobs?” Your answer should be a managed catalog:

• Endpoint management (managed app store, deployment tool) for approved software.
• Application allowlisting for executable control where feasible.
• A documented request workflow for new software with security review triggers (license, data handling, updater behavior, network access). ²

Deliverables:

• Approved software list (or “managed software catalog”).
• Software request workflow with required fields and approvers. ²

Step 4: Control elevation for exceptional installs

Some roles need installs (developers, IT support). CM-11(2) allows it, but only with explicit privileged status.

Minimum operational pattern:

• Use a privileged access management method (separate admin account, JIT elevation, or controlled sudo) tied to named identities.
• Require a ticket or documented approval for non-standard installs.
• Log elevation events and installation events; alert on anomalies (unknown installer, unusual host, repeated failures). ²

Deliverables:

• Privileged role assignment records (who has install privileges and why).
• Break-glass procedure with tight controls and post-use review. ²

Step 5: Build monitoring and periodic access review

You need ongoing proof that the control stays in place:

• Periodic review of privileged groups that permit installations.
• Spot checks of endpoints/servers for unauthorized software.
• Review of installation logs for exceptions and trends. ²

Practical tip: Tie CM-11(2) testing to your vulnerability management or endpoint hygiene reporting so it becomes routine evidence rather than a scramble during audit. ²

Step 6: Map ownership, procedure, and recurring evidence (assessment readiness)

A common failure mode is “we do this in practice” without a control narrative and evidence calendar. Treat CM-11(2) as an assessable control:

• Named control owner(s)
• Implementation procedure
• Evidence list and frequency
  This mapping is also a clean place to track exceptions. Daydream can store the control narrative, route evidence requests to IT/IAM owners, and keep an audit-ready packet aligned to CM-11(2). ¹

Required evidence and artifacts to retain

Keep evidence that shows both design (policy/standard) and operating effectiveness (config + logs).

Governance artifacts

• Software Installation Privilege Standard (defines “explicit privileged status”). ²
• RACI / control ownership and escalation path. ²

Technical artifacts

• Screenshots/exports of endpoint baseline settings (MDM/GPO), server privilege configs (sudoers, role bindings), and application control rules. ²
• Access control lists for privileged install groups (directory groups, PAM roles). ²

Operational artifacts

• Sample tickets for software requests and approvals (including denials). ²
• Installation logs (endpoint telemetry, OS event logs, EDR events, package manager logs) demonstrating installs performed under privileged identity. ²
• Exception register for any approved user-install scenarios, with compensating controls and end dates. ²

Common exam/audit questions and hangups

Expect these questions and pre-build answers:

1. “Show me that standard users can’t install software.” Provide a test account demonstration plus your baseline configuration export. ²
2. “Who can install software, and who approved it?” Provide privileged group membership plus the access request/approval record. ²
3. “How do you detect unauthorized software?” Provide endpoint inventory reports and a sample investigation ticket. ²
4. “What about developers who need packages daily?” Show your controlled elevation method and how you log installs, including guardrails for repositories and signing where applicable. ²

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails CM-11(2)	Fix
“Everyone is local admin for productivity”	Privilege is not explicit and becomes default	Remove local admin by default; implement request + managed app deployment. 2
Shared admin accounts	No accountability for who installed what	Require named admin identities; prohibit shared credentials except tightly controlled break-glass. 2
Blocking installs but allowing portable executables	Users can still run unapproved code	Add application control/allowlisting and monitor new executables in user-writable paths. 2
No evidence cadence	Control exists but cannot be proven	Define recurring evidence pulls (privileged group review, install logs, exception review) and store them in Daydream for audit packets. 1
Exceptions with no expiry	“Temporary” becomes permanent	Require end dates and periodic exception review with compensating controls. 2

Enforcement context and risk implications

NIST SP 800-53 is a control framework, not a regulator; enforcement typically occurs through contract requirements, ATO decisions, and assessment findings tied to federal program expectations. A weak CM-11(2) posture increases the chance of unauthorized software, unmanaged update mechanisms, and unreviewed data flows, which can cascade into incident response and reporting obligations depending on your environment and contracts. ²

A practical 30/60/90-day execution plan

Use this to drive delivery without guessing calendar dates. Treat these as phases, not promises.

First 30 days (stabilize and scope)

• Name control owners (Endpoint, IAM/PAM, GRC) and publish the Software Installation Privilege Standard mapped to CM-11(2). ²
• Inventory install pathways: local admin, package managers, app stores, browser extension policies, scripting tools. ²
• Start removing local admin from the highest-risk populations and endpoints; document any exceptions immediately. ²

By 60 days (enforce and operationalize)

• Deploy managed software catalog and the request workflow for anything outside the catalog. ²
• Implement privileged elevation controls for teams that must install software; require named accounts and log collection. ²
• Stand up an evidence packet in Daydream: policy/standard, baseline exports, privileged group membership, and sample tickets/logs. ¹

By 90 days (prove it and make it repeatable)

• Run a privileged access review focused on “can install software” roles; remediate stale access. ²
• Perform a targeted hunt for unauthorized software and close gaps (allowlisting gaps, user-writable execution paths, unmanaged extensions). ²
• Formalize recurring evidence pulls and exception reviews so the control stays audit-ready. ²

Frequently Asked Questions

Does CM-11(2) require a privileged access management (PAM) tool?

No. It requires that installation happens only with explicit privileged status. A PAM tool can make that easier to manage and prove, but separate admin accounts with strong governance can also satisfy the requirement. ¹

Are browser extensions considered “software installation”?

Treat them as in scope if they introduce executable code or change data flows. The safe operational stance is to manage extensions through enterprise policy and block user-driven installs outside approved lists. ²

Can developers install packages from public repositories?

They can only do so under explicit privileged status if the action installs software onto managed systems. Control the elevation path, log the activity, and consider repository and signing guardrails as part of your secure configuration practice. ²

What evidence is most persuasive to auditors for CM-11(2)?

A baseline showing standard users lack install rights, a list of privileged install roles with approvals, and logs or tickets tying real installs to privileged identities. Keep a small set of representative samples that you can reproduce on request. ²

How do we handle emergency installs during incidents?

Use a break-glass process that grants explicit privileged status, records who approved and who acted, and triggers a post-incident review to remove access and document what was installed. ²

What if a third party needs to install software on our systems?

Require the third party to use your privileged access method (named accounts, approved roles, logged sessions) and your change/request process. Treat third-party installs as privileged admin actions with the same evidence requirements. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5