{
  "title": "How to Configure Windows and Linux Systems for NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - CM.L2-3.4.7 to Disable Nonessential Functions",
  "date": "2026-04-09",
  "author": "Lakeridge Technologies",
  "featured_image": "/assets/images/blog/2026/4/how-to-configure-windows-and-linux-systems-for-nist-sp-800-171-rev2-cmmc-20-level-2-control-cml2-347-to-disable-nonessential-functions.jpg",
  "content": {
    "full_html": "<p>This post explains how to implement NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control CM.L2-3.4.7 — disable nonessential functions — on Windows and Linux systems, with step-by-step commands, group policy and automation examples, and practical advice for small business environments.</p>\n\n<h2>Understanding CM.L2-3.4.7 and the Compliance Framework context</h2>\n<p>CM.L2-3.4.7 requires organizations to limit system functionality to only what is essential for mission and business operations. In practice this means you must inventory system capabilities, identify nonessential services/protocols/features (e.g., Telnet, FTP, unused daemons, legacy APIs), and disable or remove them in a controlled manner. Within the Compliance Framework of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2, this is a configuration management control intended to reduce attack surface and support the protection of Controlled Unclassified Information (CUI).</p>\n\n<h2>Inventory and a risk-based approach (first steps)</h2>\n<p>Begin with an inventory: list OS versions, installed packages, enabled services, listening ports, and configured features for all endpoints and servers. Use tools such as Microsoft Defender Inventory, SCCM/Intune, or a lightweight Nmap/Netstat sweep and Linux package managers (dpkg/rpm) for small environments. Prioritize by risk and business impact: systems that host CUI, domain controllers, file servers and jump boxes get higher priority. Document allowed services in a baseline configuration profile (gold image) and record exceptions with business justification and expiration.</p>\n\n<h2>How to disable nonessential functions on Windows (practical steps)</h2>\n<p>On Windows, nonessential functions are usually services, Windows features, scheduled tasks, and legacy protocols. A standard hardening sequence is: 1) identify services with Get-Service and listening ports with Get-NetTCPConnection or netstat -ano; 2) test disabling in a staging VM; 3) disable/stop the service and set startup to Disabled; 4) apply via Group Policy / Intune / SCCM for scale. Example interactive commands:</p>\n<pre><code># Stop and disable a service (e.g., Print Spooler)\nStop-Service -Name Spooler -Force\nSet-Service -Name Spooler -StartupType Disabled\n\n# Disable SMBv1 (if still present)\nDisable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol\n\n# View listening ports\nGet-NetTCPConnection -State Listen | Format-Table LocalAddress,LocalPort,OwningProcess\n</code></pre>\n\n<h3>Group Policy and automation examples for Windows</h3>\n<p>Use Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → System Services to set service startup types centrally, or use Group Policy Preferences to run scripts. For modern management, use Intune device configuration profiles or PowerShell DSC / Salt to enforce desired state. Example GPO approach for Print Spooler: configure the service startup as Disabled and apply a Scheduled Task to re-stop the service as a fallback. Keep a change request and rollback plan for any disabling that impacts end users (e.g., printing in a particular office).</p>\n\n<h2>How to disable nonessential functions on Linux (practical steps)</h2>\n<p>On Linux, the equivalent items are systemd services, installed packages, kernel modules, and open ports. Steps: audit with ss -tuln, systemctl list-unit-files --state=enabled, and package lists (apt list --installed or rpm -qa). For a given service:</p>\n<pre><code># Stop + disable + mask a service\nsudo systemctl stop telnet.socket\nsudo systemctl disable telnet.socket\nsudo systemctl mask telnet.socket\n\n# Remove an unneeded package (Debian/Ubuntu)\nsudo apt-get remove --purge telnetd -y\nsudo apt-get autoremove -y\n</code></pre>\n<p>To prevent kernel modules from loading, add a blacklist file in /etc/modprobe.d/ (for example, create /etc/modprobe.d/blacklist-usb-storage.conf with \"blacklist usb-storage\") and rebuild initramfs (update-initramfs -u) if required. Carefully test module blacklisting on systems that rely on the hardware.</p>\n\n<h3>Automation example with Ansible</h3>\n<p>For small businesses that want repeatable enforcement, Ansible playbooks are efficient. Example snippet for disabling services and removing packages:</p>\n<pre><code>- name: Harden servers - remove telnet and disable print spooler\n  hosts: servers\n  become: yes\n  tasks:\n    - name: Remove telnet package\n      apt:\n        name: telnetd\n        state: absent\n      when: ansible_facts['os_family'] == 'Debian'\n\n    - name: Disable and mask telnet service\n      systemd:\n        name: telnet.socket\n        enabled: no\n        masked: yes\n        state: stopped\n</code></pre>\n<p>Use CI/CD or Ansible Tower/AWX to run against inventories and log changes. For Windows, use WinRM-enabled Ansible modules or Group Policy/Intune as the enforcement mechanism.</p>\n\n<h2>Operational considerations, monitoring, and verification</h2>\n<p>Disabling functions is not a one-time task: integrate into change management and patch cycles. Build automated compliance checks: periodic scans with Nessus/OpenVAS, CIS-CAT, or customized scripts that verify service states and listening ports. Keep baselines in version-controlled configuration repositories and enforce via configuration management tools. For exceptions, maintain an approvals log with compensating controls (e.g., firewall rules, host-based IDS) and a re-evaluation date. Finally, collect and centralize logs (Windows Event Forwarding, syslog/rsyslog -> SIEM) so you can detect attempts to re-enable forbidden services or unexpected new listeners.</p>\n\n<h2>Risk of not implementing CM.L2-3.4.7</h2>\n<p>Failing to disable nonessential functions leaves unnecessary attack surfaces that adversaries can exploit — e.g., legacy protocols like Telnet/FTP enable credential capture; unused services give remote code execution paths; exposed management interfaces enable lateral movement. For organizations handling CUI, this increases the risk of data breach, contract loss with DoD or prime contractors, regulatory penalties, and reputational damage. From a cost perspective, incident remediation and forensic response often far exceed the investment required to harden and maintain baselines.</p>\n\n<p>In summary, meeting CM.L2-3.4.7 under the Compliance Framework requires a disciplined, repeatable process: inventory systems, apply a risk-based decision on what is essential, disable or remove nonessential functions with testing and change control, automate enforcement and monitoring, and document exceptions. For small businesses, start by hardening high-value assets (file servers, domain controllers), use Group Policy/Intune or Ansible for consistency, and run periodic verification scans to prove compliance.</p>",
    "plain_text": "This post explains how to implement NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control CM.L2-3.4.7 — disable nonessential functions — on Windows and Linux systems, with step-by-step commands, group policy and automation examples, and practical advice for small business environments.\n\nUnderstanding CM.L2-3.4.7 and the Compliance Framework context\nCM.L2-3.4.7 requires organizations to limit system functionality to only what is essential for mission and business operations. In practice this means you must inventory system capabilities, identify nonessential services/protocols/features (e.g., Telnet, FTP, unused daemons, legacy APIs), and disable or remove them in a controlled manner. Within the Compliance Framework of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2, this is a configuration management control intended to reduce attack surface and support the protection of Controlled Unclassified Information (CUI).\n\nInventory and a risk-based approach (first steps)\nBegin with an inventory: list OS versions, installed packages, enabled services, listening ports, and configured features for all endpoints and servers. Use tools such as Microsoft Defender Inventory, SCCM/Intune, or a lightweight Nmap/Netstat sweep and Linux package managers (dpkg/rpm) for small environments. Prioritize by risk and business impact: systems that host CUI, domain controllers, file servers and jump boxes get higher priority. Document allowed services in a baseline configuration profile (gold image) and record exceptions with business justification and expiration.\n\nHow to disable nonessential functions on Windows (practical steps)\nOn Windows, nonessential functions are usually services, Windows features, scheduled tasks, and legacy protocols. A standard hardening sequence is: 1) identify services with Get-Service and listening ports with Get-NetTCPConnection or netstat -ano; 2) test disabling in a staging VM; 3) disable/stop the service and set startup to Disabled; 4) apply via Group Policy / Intune / SCCM for scale. Example interactive commands:\n# Stop and disable a service (e.g., Print Spooler)\nStop-Service -Name Spooler -Force\nSet-Service -Name Spooler -StartupType Disabled\n\n# Disable SMBv1 (if still present)\nDisable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol\n\n# View listening ports\nGet-NetTCPConnection -State Listen | Format-Table LocalAddress,LocalPort,OwningProcess\n\n\nGroup Policy and automation examples for Windows\nUse Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → System Services to set service startup types centrally, or use Group Policy Preferences to run scripts. For modern management, use Intune device configuration profiles or PowerShell DSC / Salt to enforce desired state. Example GPO approach for Print Spooler: configure the service startup as Disabled and apply a Scheduled Task to re-stop the service as a fallback. Keep a change request and rollback plan for any disabling that impacts end users (e.g., printing in a particular office).\n\nHow to disable nonessential functions on Linux (practical steps)\nOn Linux, the equivalent items are systemd services, installed packages, kernel modules, and open ports. Steps: audit with ss -tuln, systemctl list-unit-files --state=enabled, and package lists (apt list --installed or rpm -qa). For a given service:\n# Stop + disable + mask a service\nsudo systemctl stop telnet.socket\nsudo systemctl disable telnet.socket\nsudo systemctl mask telnet.socket\n\n# Remove an unneeded package (Debian/Ubuntu)\nsudo apt-get remove --purge telnetd -y\nsudo apt-get autoremove -y\n\nTo prevent kernel modules from loading, add a blacklist file in /etc/modprobe.d/ (for example, create /etc/modprobe.d/blacklist-usb-storage.conf with \"blacklist usb-storage\") and rebuild initramfs (update-initramfs -u) if required. Carefully test module blacklisting on systems that rely on the hardware.\n\nAutomation example with Ansible\nFor small businesses that want repeatable enforcement, Ansible playbooks are efficient. Example snippet for disabling services and removing packages:\n- name: Harden servers - remove telnet and disable print spooler\n  hosts: servers\n  become: yes\n  tasks:\n    - name: Remove telnet package\n      apt:\n        name: telnetd\n        state: absent\n      when: ansible_facts['os_family'] == 'Debian'\n\n    - name: Disable and mask telnet service\n      systemd:\n        name: telnet.socket\n        enabled: no\n        masked: yes\n        state: stopped\n\nUse CI/CD or Ansible Tower/AWX to run against inventories and log changes. For Windows, use WinRM-enabled Ansible modules or Group Policy/Intune as the enforcement mechanism.\n\nOperational considerations, monitoring, and verification\nDisabling functions is not a one-time task: integrate into change management and patch cycles. Build automated compliance checks: periodic scans with Nessus/OpenVAS, CIS-CAT, or customized scripts that verify service states and listening ports. Keep baselines in version-controlled configuration repositories and enforce via configuration management tools. For exceptions, maintain an approvals log with compensating controls (e.g., firewall rules, host-based IDS) and a re-evaluation date. Finally, collect and centralize logs (Windows Event Forwarding, syslog/rsyslog -> SIEM) so you can detect attempts to re-enable forbidden services or unexpected new listeners.\n\nRisk of not implementing CM.L2-3.4.7\nFailing to disable nonessential functions leaves unnecessary attack surfaces that adversaries can exploit — e.g., legacy protocols like Telnet/FTP enable credential capture; unused services give remote code execution paths; exposed management interfaces enable lateral movement. For organizations handling CUI, this increases the risk of data breach, contract loss with DoD or prime contractors, regulatory penalties, and reputational damage. From a cost perspective, incident remediation and forensic response often far exceed the investment required to harden and maintain baselines.\n\nIn summary, meeting CM.L2-3.4.7 under the Compliance Framework requires a disciplined, repeatable process: inventory systems, apply a risk-based decision on what is essential, disable or remove nonessential functions with testing and change control, automate enforcement and monitoring, and document exceptions. For small businesses, start by hardening high-value assets (file servers, domain controllers), use Group Policy/Intune or Ansible for consistency, and run periodic verification scans to prove compliance."
  },
  "metadata": {
    "description": "Step-by-step guidance to identify, disable, and manage nonessential services and functions on Windows and Linux systems to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (CM.L2-3.4.7) requirements.",
    "permalink": "/how-to-configure-windows-and-linux-systems-for-nist-sp-800-171-rev2-cmmc-20-level-2-control-cml2-347-to-disable-nonessential-functions.json",
    "categories": [],
    "tags": []
  }
}