This practice is the operational complement to CM.L2-3.4.8 (Application Execution Policy). Where CM.L2-3.4.8 establishes the whitelist, CM.L2-3.4.9 enforces that users can’t circumvent it by installing their own software. If users have local admin rights, this practice becomes nearly impossible. If users don’t have those rights and you’re monitoring for installation attempts, you meet the standard. User restrictions also tie back to AC.L2-3.1.1, where you define and enforce access rights for each system role.
What the assessor is actually evaluating
The assessor is checking whether you’ve actually removed the ability for users to install software, or at minimum, whether you’re catching and preventing it.
Do users have local administrator rights? If the answer is yes, then CM.L2-3.4.9 is going to be very difficult. Users with admin rights can install anything, bypass any control, and remove any restriction. The assessor will probe this directly.
Is software installation technically prevented? If users don’t have admin rights, are they actually unable to install software? Or are there ways they can get around it? Can they run installers from USB drives? Can they extract portable applications to their user directory and execute them? Can they use PowerShell to download and run scripts?
Are installation attempts monitored and logged? If a user tries to install software despite restrictions, is that attempt logged? Does someone review those logs? Is there a process to investigate unauthorized installation attempts?
What’s the consequence of attempting unauthorized installation? Is it just logged, or is there an escalation process? Do users know that installation attempts are being monitored? (Awareness is a deterrent.)
What a realistic SSP definition looks like
[Organization Name] prohibits user-installed software on systems within the CUI boundary. Users are not granted local administrator rights on workstations. Installation of software requires prior approval from the IT Director and is performed by IT personnel, not by end users.
Users who attempt to install software without authorization are blocked by local security policies that remove execution rights from user-accessible directories and disable the Windows Installer service for unauthorized installations. Installation attempts are logged through Windows Security event logs and application whitelisting logs. The IT Director reviews installation attempts monthly to identify policy violations and takes corrective action for unauthorized attempts.
Users are informed through acceptable use policy that software installation is prohibited and that unauthorized installation attempts will be detected and investigated.
Key details:
It explicitly states users don’t have admin rights. Not “users have limited rights” but a clear statement that local administrator rights are not granted.
It describes the technical controls that prevent installation. Security policies that block execution in user directories. Disabled Windows Installer for unauthorized installs. These are real, verifiable controls.
It includes monitoring and review. Installation attempts are logged. Someone actually reviews those logs. There’s a frequency (monthly) and an action (corrective action for violations).
It includes a user awareness component. Users are told that installation is prohibited and that it will be detected. That increases voluntary compliance.
How to present your evidence
- User rights policy document showing users are not administrators
- Local security policy or group policy objects restricting user execution rights
- Application whitelisting logs showing blocked installations
- Windows event log entries showing installation attempts and denials
- Records of policy reviews for unauthorized installation attempts
- Acceptable use policy mentioning software installation prohibition
- User communication about software installation restrictions
When the assessor reaches CM.L2-3.4.9:
Your user rights policy. Document or group policy showing that non-administrative users do not have the rights to install software. Name specific things they can’t do: run installers, access HKLM registry, modify system directories, install services.
System configuration evidence. Pull up a workstation and show what a standard user can and can’t do. Try to run an installer and show it being blocked. Open File Properties and show that User Program Files directory isn’t writable. Open Services and show Windows Installer is disabled or restricted.
Installation attempt logs. Pull security event logs from a workstation showing installation attempts and failures. Or whitelist logs showing blocked executables. The goal is to prove that when users try to install software, it’s blocked and logged.
Review records. Document that you actually look at the logs. A spreadsheet or email from the IT Director saying “reviewed installation logs for [month]. Found 3 unauthorized attempts. All blocked successfully” is sufficient evidence.
User awareness. Point to your acceptable use policy and show that it mentions software installation is prohibited. If you’ve sent communications to users about this, include those. The awareness piece shows it’s not a surprise control, it’s a known policy.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
Users have local administrator rights.** If users are admins on their workstations, they can install anything. This is a hard stop for CM.L2-3.4.9. You can't claim to control user-installed software if users have full system rights.
No technical controls preventing installation.** Security policy says no, but technical controls aren't in place. If users want to circumvent the policy, they can find a way without enforcement mechanisms. Technical controls are essential—policy alone is insufficient.
No monitoring or logging of installation attempts.** You claim installations are blocked, but you have no evidence of monitoring. The assessor will ask where the logs are, and you won't be able to show them.
Installation attempts are logged but not reviewed.** The logs exist but nobody looks at them. If an unauthorized installation happens, would you know? If someone tries and fails, nobody notices.
Users don't know the policy exists.** You have a restrictive policy but users aren't informed. They try to install software, are surprised when it fails, and there's no prior communication about the prohibition.
Users without admin rights. Clear group policies preventing installation. Logs showing that unauthorized installation attempts are blocked. Monthly or quarterly review of those logs. User communication making the policy known. When the assessor can verify that users genuinely cannot install software and that any attempts are detected and reviewed, they check the box and move on.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
If your MSP manages workstations, they should be implementing this control on your behalf.
Ask your MSP for:
Their user rights policy. How do they prevent users from installing software? Are local admin rights removed? What group policies or configurations are in place?
Monitoring and logging of installation attempts. Are they logging attempted installations? How often do they review the logs? What’s their escalation process for unauthorized attempts?
Log samples or reports. Ask to see examples of installation attempts being blocked and logged. If they’ve never seen a blocked installation attempt, that’s either suspicious or it means the control is working really well.
User communication. Do they inform users about the policy? Is there an acceptable use agreement? Users should know they can’t install software and that they should request through the proper channel.
Implementation verification. Ask them to pull up a workstation and demonstrate that a standard user cannot install software. Try to run an installer and show it failing. This is the ultimate proof.
As software delivery evolves, "installation" becomes harder to define. Portable applications that don't require installation, browser-based applications, and script-based tools can bypass traditional installation controls. If your environment uses these, you need a strategy. The best approach is to combine user rights restrictions with application whitelisting (CM.L2-3.4.8). If portable applications can't execute because they're not whitelisted, they can't run even if users aren't admins. Document your approach if you're using this combination.
This page covers CM.L2-3.4.9 from NIST SP 800-171 Rev 2 (3.4.9). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.