CMMC Level 2 Practice 3.4.9: Control and monitor user-installed software

To meet the cmmc level 2 practice 3.4.9: control and monitor user-installed software requirement, you must prevent unapproved software from being installed by users on in-scope systems, and you must continuously detect, log, and respond to installation attempts and newly introduced applications. Operationalize it by enforcing allowlisting or equivalent install controls, centralizing software inventory, and retaining audit-ready evidence of monitoring and remediation. ¹

Key takeaways:

• Block or tightly gate user-driven installs on all CUI-scoped endpoints and servers; exceptions must be approved and tracked. ²
• Monitoring must be real, continuous, and provable: inventory, alerts, logs, and tickets that show you acted. ²
• Assessors look for operational evidence more than policy text; build recurring evidence capture into your control runbook. ³

CMMC Level 2 requires alignment to NIST SP 800-171 Rev. 2 practices for protecting Controlled Unclassified Information (CUI) in non-federal environments. Practice 3.4.9 focuses on a high-frequency failure mode: end users installing software that introduces malware, data exfiltration paths, unauthorized remote access tools, or unpatched applications outside your vulnerability management program. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat 3.4.9 as a combined technical control + operational process requirement. The technical side limits who can install software and what can run. The process side ensures you can show who requested software, who approved it, how it was deployed, and what you did when someone bypassed the process. ²

This page translates the requirement into implementable steps you can hand to IT and Security, plus the evidence package you should retain for a CMMC assessment. It also highlights the audit “hangups” that commonly slow teams down, especially in mixed environments with BYOD, developers, and third-party tools.

Regulatory text

Requirement (mapped): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.4.9 (Control and monitor user-installed software).” ⁴

What an operator must do (in plain terms):

• Control: Put guardrails in place so users cannot install software freely on in-scope systems. Any installation path that remains must require authorization (role-based permissions, administrative elevation controls, allowlisting, or managed software deployment). ²
• Monitor: Detect and investigate new software appearing on systems, including failed install attempts or execution of unapproved applications, and show a response workflow. ²

Plain-English interpretation of the requirement

3.4.9 expects you to know what software is running on your CUI-scoped assets and to prevent “drive-by installs” that bypass security review. If a user can install a browser plugin, remote access tool, or random freeware without detection, you will struggle to demonstrate control of your environment under CMMC Level 2. ¹

Treat the requirement as three outcomes:

1. Only approved software gets installed (or executed) on in-scope systems.
2. You can prove detection of new or unauthorized software.
3. You can prove response (removal, exception approval, or compensating control). ²

Who it applies to (entity and operational context)

Entities: Defense Industrial Base (DIB) organizations and other federal contractors that handle CUI and must meet CMMC Level 2 requirements through NIST SP 800-171 Rev. 2 alignment. ⁵

In-scope assets and situations:

• Endpoints, servers, and virtual machines that store, process, or transmit CUI, plus systems that provide security or administrative functions supporting that environment. ²
• Users with local admin rights, power users, engineers, IT staff, and contractors with elevated permissions.
• Third-party software installers, browser extensions, scripting languages, package managers, and “portable” apps that can run from user directories.

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

Step 1: Define the “in-scope software control boundary”

• Identify which endpoints/servers are part of your CUI environment and which are out-of-scope.
• Document the control boundary in your SSP and internal scoping notes so IT applies controls consistently. ⁶

Operator tip: If you cannot clearly state which assets are in scope, you will not be able to show consistent enforcement of installation controls.

Step 2: Set a clear software authorization model

Pick one model per platform, document it, and enforce it:

• Allowlist model: Only approved applications (hash/path/publisher) can execute, and installation is limited to managed deployment.
• Controlled install model: Users lack admin rights; software is installed through IT-managed tools after approval.
• Exception model: Limited groups (for example, developers) can install from approved repositories under enhanced monitoring and rapid removal requirements. ²

Step 3: Remove local admin rights by default

• Set endpoint standards: users are standard users; admin elevation is time-bound and logged.
• Maintain a list of approved privileged groups and justify each one. ²

Common assessor focus: “Show me who can install software today.” Have a crisp answer and a current list.

Step 4: Implement technical controls to prevent unapproved installs/execution

Minimum control set to operationalize quickly:

• Application control / allowlisting (where feasible) for in-scope endpoints and servers.
• Software deployment tooling to install approved software centrally.
• Block common user-install vectors (user-writable execution paths, unsigned installers, unauthorized package managers) based on your environment’s risk profile. ²

Step 5: Implement monitoring that produces actionable signals

Monitoring must cover both presence and attempts:

• Software inventory feed: near-real-time or scheduled discovery of installed applications.
• Alerting on unauthorized software: detection rules for known remote access tools, unauthorized browsers, unsigned binaries, new persistence mechanisms, and software installed outside managed tooling.
• Central logging: endpoint logs and security events forwarded to a central system so you can show historical records. ²

Step 6: Build the operational workflow (request → approve → deploy → verify)

Create a simple workflow that generates evidence:

1. User submits software request with business justification and system scope.
2. Security/IT reviews: licensing, vulnerability posture, vendor legitimacy, and data handling implications.
3. Approval recorded with version, publisher, and scope.
4. Installation performed via managed deployment or controlled admin action.
5. Post-install verification: inventory confirms installed version; monitoring rules updated if needed. ²

Step 7: Define response actions for unauthorized installs

Your runbook should specify:

• Triage and containment (isolate host if needed).
• Remove software and confirm removal via inventory.
• Root cause: admin rights misuse, policy gap, exception abuse.
• Prevent recurrence: tighten controls, update allowlist/denylist, user coaching, disciplinary path if appropriate. ²

Step 8: Prove “control operation and recurring evidence capture”

Turn 3.4.9 into a control you can run monthly/quarterly:

• Sample endpoints for unauthorized software checks.
• Review exceptions list and privileged access list.
• Confirm alert-to-ticket outcomes for unauthorized software events. ⁶

Where Daydream fits (naturally): teams often implement the tooling but fail evidence collection. Daydream can map 3.4.9 to a documented control and schedule recurring evidence pulls (inventory exports, admin group lists, alert/ticket samples) so you do not rebuild the package before an assessment. ³

Required evidence and artifacts to retain

Keep evidence that shows both design and operation:

Policy and design artifacts

• Software installation / application control policy for in-scope systems.
• Standard build configurations showing removal of local admin rights.
• Approved software catalog (name, publisher, version constraints, approval owner).
• Exception register (who, why, expiration, compensating monitoring). ²

Operational evidence (what assessors ask for)

• Current list of users/groups with local admin or install privileges on in-scope systems.
• Software inventory reports for a defined period, with timestamps.
• SIEM/EDR alerts for unauthorized software, plus linked incident/service tickets showing investigation and resolution.
• Change records or deployment logs for approved installs.
• Samples of rejected install attempts or blocked executions (screenshots/log extracts) tied to a ticket. ¹

Common exam/audit questions and hangups

Expect questions like:

• “Who can install software on CUI endpoints, and how do you know the list is current?” ²
• “Show me how you detect new software installed outside your process.” ²
• “Walk through one unauthorized software event from alert to closure.” ³
• “How do you handle browser extensions, portable apps, and scripts?” ²
• “How do you manage third-party remote support tools?” ²

Hangups that slow assessments:

• Incomplete scoping (out-of-scope machines still connecting to CUI services).
• Exceptions that never expire.
• Inventory data that is not authoritative or not retained long enough to show a pattern of operation. ³

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails 3.4.9	Fix
Policy says “no unauthorized software,” but users have local admin	Control is unenforced	Remove local admin by default; enforce elevation workflows. 2
Relying only on annual software inventory	Monitoring is not operational	Centralize endpoint telemetry and review it on a recurring cadence. 2
Exceptions handled in email/DMs	No traceability	Use a ticketed approval workflow and an exception register. 3
Ignoring browser extensions and user profile installs	Common bypass path	Treat extensions as software; control via managed policies and monitoring. 2
No linkage between alerts and response	“Monitor” without action	Require tickets, remediation notes, and verification evidence. 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. ³

Risk remains practical and immediate: unauthorized software frequently becomes the entry point for credential theft, remote access, or unmanaged vulnerabilities, which threatens CUI confidentiality and the credibility of your CMMC Level 2 assessment posture. The assessment risk is also straightforward: if you cannot show both prevention and monitoring evidence, you will struggle to demonstrate practice implementation. ¹

Practical 30/60/90-day execution plan

Use phased execution without assuming a specific calendar duration for tool rollouts in your environment.

First 30 days (Immediate stabilization)

• Confirm CUI scope and list in-scope endpoints/servers. ³
• Freeze uncontrolled installs: remove local admin for standard users where feasible; require tickets for installs.
• Stand up a baseline software inventory export and store it as evidence. ²
• Write the runbook: request, approval, deployment, verification, unauthorized software response. ²

Next 60 days (Enforcement + monitoring maturity)

• Implement or tighten application control/allowlisting for critical in-scope systems first.
• Centralize logging for install events and application execution signals.
• Create detection rules and a response workflow with ticket linkage. ²
• Build the approved software catalog and exception register. ²

Next 90 days (Assessment-ready evidence cadence)

• Run recurring control checks and capture evidence packages (inventory snapshots, admin group lists, exception review results).
• Perform tabletop testing: simulate an unauthorized install, generate an alert, open a ticket, remove the software, and retain the full chain as proof. ³
• Update SSP/control narratives so the story matches what the tools and tickets show. ³

Frequently Asked Questions

Does 3.4.9 require full application allowlisting?

The requirement is to control and monitor user-installed software, not to implement a specific technology. Allowlisting is a strong method, but you can meet the intent with tightly controlled admin rights, managed deployment, and provable monitoring and response. ²

Are browser extensions and plugins “software” for this control?

Treat them as software in practice because users can add functionality and introduce risk without traditional installs. Control them through centralized management and monitor for unauthorized additions on in-scope endpoints. ²

What if developers need to install tools frequently?

Use an exception model with guardrails: approved repositories, documented exceptions with expiration, enhanced monitoring, and rapid removal requirements. Keep the evidence trail for each exception and periodic reviews. ¹

How do we prove “monitoring” to a CMMC assessor?

Show software inventory outputs over time, alerting/detection examples for unauthorized software, and the corresponding tickets that document investigation and remediation. Assessors typically want to trace at least one event end-to-end. ⁶

Are third-party remote support tools allowed?

They can be, but treat them as high-risk software: require explicit approval, restrict installation to IT, monitor for unauthorized installs, and confirm configurations align with your access control practices. Retain approvals and monitoring evidence. ²

What evidence is most commonly missing?

Teams often have a policy and a tool but lack recurring evidence that the control runs: current admin-rights lists, exception reviews, and closed-loop tickets tied to alerts. Build evidence capture into the operating cadence. ³

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

5. 32 CFR Part 170; DoD CMMC Program Guidance

6. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2