This is a foundational security principle. Every service running is a potential attack surface. Every open port is a potential entry point. CM.L2-3.4.6 requires that you start from a minimal configuration and only enable what’s actually needed. This is one place where documentation and reality have to match exactly, because the assessor can verify this by looking at the systems themselves. Least functionality ties directly to SC.L2-3.13.1, which requires you to monitor and analyze system behavior for unauthorized activity. You can’t effectively monitor what’s happening on over-configured systems.
What the assessor is actually evaluating
The assessor will look at the actual systems and compare them to your documented configuration baseline. They’re checking:
Do you have a baseline? Not just “we configure systems the way they come.” Do you have a documented standard for what runs on servers that handle CUI? For workstations? For network infrastructure? The baseline doesn’t have to be complicated. It just has to exist and be specific.
Is it minimal? The baseline should disable unnecessary services and protocols. On a Windows server that’s only being used as a file server, why is the print spooler running? On a Linux system that’s a firewall, why are a dozen unnecessary services enabled? The assessor will look for things that are running and ask why.
Does the actual configuration match the baseline? This is where documentation and reality collide. If your baseline says certain services should be disabled, the assessor will check whether they actually are. If you document a port as closed, they’ll verify it’s closed. Mismatches create findings.
Can you explain the reasoning? When the assessor sees something disabled or enabled, you should be able to explain why. “That service isn’t needed for this system’s function” is a valid answer. “I don’t know, it was already disabled” is not.
What a realistic SSP definition looks like
[Organization Name] configures all systems with the principle of least functionality. Servers are deployed using a hardened baseline that includes only the services, protocols, and software necessary for their intended function. Unnecessary services such as file sharing, printing, remote access, and web serving are disabled on servers that do not require them. Unused network protocols are disabled.
The hardening baseline for servers is documented in [location, e.g. Configuration Baseline v1.2]. Workstations are deployed with default operating system configurations modified to disable non-essential services such as remote desktop, print spooler, and unnecessary background services. The specific services enabled on each system type are documented and reviewed annually.
All systems are inventoried, and the inventory includes the system's intended function and the services expected to be active. Any service or software that appears in the environment but is not in the inventory is escalated to the IT Director for review and remediation.
Key details:
It references a specific baseline document. Not “systems are hardened.” The baseline is documented and can be pulled up. “Configuration Baseline v1.2” is something concrete the assessor can look at.
It lists examples of what gets disabled. File sharing, printing, remote access, unnecessary services. These are concrete examples that show you’ve thought about the attack surface.
It covers both servers and workstations. Different systems have different purposes and different baselines. The SSP should acknowledge that.
It includes an inventory with expected configurations. You know what systems exist, what they’re supposed to do, and what services should be running on them. Anything else is out of place and gets investigated.
How to present your evidence
- Hardening baseline document for servers (Windows, Linux, or both)
- Hardening baseline or configuration standard for workstations
- System inventory listing each system and its intended function
- Configuration screenshots or system output showing enabled/disabled services
- Port scan results or firewall configuration showing only necessary ports open
- Documentation of the rationale for each enabled service
When the assessor reaches CM.L2-3.4.6:
Your hardening baseline document. This is the core evidence. It should be a clear document that describes what services should be enabled and disabled on each system type. For Windows, it might list the specific services to disable (Print Spooler, Remote Desktop, etc.). For Linux, it might specify the runlevel and which services should be active. It doesn’t have to be long. It has to be specific and current.
Your system inventory. A spreadsheet listing every system in scope for CMMC, its function, and the baseline it follows. When the assessor asks “why does that server have 15 services running,” you point to the inventory and say “that’s not on our list of approved systems. We’ll investigate it.”
Configuration evidence from your systems. Pull up a Windows server and show the assessor the Services view with disabled services visible. Run a netstat or nmap scan to show which ports are listening. Show a Linux system with systemctl disabled for unnecessary services. This is where documentation and reality meet.
Explanations. When the assessor asks “why is this service enabled,” have an answer ready. “It’s required for our backup solution.” “It’s needed for domain membership.” “It’s a dependency for another essential service.” Random services running with no explanation will generate findings.
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
No baseline document at all.** The assessor asks to see your hardening baseline and you don't have one. Systems exist, but there's no documented standard for what should be running on them.
Systems don't match the baseline.** You have a baseline that says certain services should be disabled, but the assessor checks the actual systems and they're still enabled. Or you claim a service is disabled but it's actually running. Inconsistency creates findings.
Too many services enabled without justification.** A file server has 20 services running. The assessor asks why, and you can't explain half of them. "It came enabled by default" is not a reason. You should know why each service is there.
No system inventory.** You don't know what systems exist or what they're supposed to be doing. When the assessor asks how you ensure configurations are consistent, you have no answer.
A clear, documented baseline. Systems that match the baseline. Explanations for everything enabled. An inventory showing the assessor knows the landscape. When the assessor can pick a random system, compare it to your baseline, and find them aligned, 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.
Screenshots of config baselines aren't enough. Assessors want live demos. They want to see you navigate the actual console, pull up a running system, and show that it matches the documented baseline. Not a PDF from last quarter. Have the admin portal open and ready.
If you use an MSP/MSSP
If your MSP manages system hardening, you should still maintain a documented baseline and verify compliance periodically.
A mature MSSP will:
Have standard baselines for different system roles. Not “we harden systems.” They have documented, repeatable baselines that are applied to all systems of a given type.
Provide hardening reports. They deploy a system according to the baseline and document it. You get that documentation for your evidence.
Maintain the baseline over time. Baselines need to be updated as new security guidance comes out or as business needs change. The MSSP should track baseline versions and apply updates to systems.
Notify you of deviations. If something is running on a system that shouldn’t be there, the MSSP should flag it. That’s part of ongoing hardening management.
When the assessor asks about your baseline, you should be able to produce it. If the MSSP has it and you don’t, ask them for it. Make it part of your evidence package. You can’t outsource compliance to the MSP. You have to be able to demonstrate it.
If you're dealing with a DoD contractor or an environment that uses DoD STIGs (Security Technical Implementation Guides), those are pre-built baselines that have been vetted for CUI systems. Using a published STIG baseline is strong evidence. Assessors often recognize them and trust that they've been hardened appropriately. If your MSSP has applied a STIG to your systems, make sure you have that documentation. Reference it in your SSP.
This page covers CM.L2-3.4.6 from NIST SP 800-171 Rev 2 (3.4.6). 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.