1Overview
CM.L2-3.4.6 applies the principle of least functionality. It requires that systems be configured to provide only essential capabilities, so that everything not needed is removed or disabled and the attack surface shrinks to what the work actually requires. It is a five-point requirement that cannot be deferred on a plan of action.
Every capability a system offers is something an attacker can potentially use, so a system that does only what it needs to is safer than one loaded with features no one uses. This control asks the organization to decide what capabilities are essential and to configure systems to provide only those, stripping away the rest. It is the configuration expression of a simple security idea: less is safer. Its five-point weight reflects how much attack surface a general-purpose system carries by default and how much of that this control removes.
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
The principle of least functionality is the configuration cousin of least privilege: just as accounts should have only the access they need, systems should have only the capabilities they need. The control asks the organization first to define which capabilities are essential, and then to configure systems so only those are present, which necessarily means identifying and removing the nonessential. It sets up the more granular control at 3.4.7, which addresses specific nonessential programs, ports, protocols, and services.
2The Assessment Objectives
NIST SP 800-171A frames 3.4.6 around two objectives: define essential capabilities, and configure systems to provide only those.
Essential system capabilities are defined based on the principle of least functionality. The organization has decided what capabilities systems actually need.
The system is configured to provide only the defined essential capabilities. Systems actually provide only what was defined as essential.
The two objectives are defining the essential set and configuring systems to it. The common gap is at objective [b], where essential capabilities are defined but systems still carry a great deal of nonessential functionality that was never stripped. The assessor looks for systems actually reduced to their essential capabilities, not just a definition of what those are.
3Failure Patterns
The failures are about systems loaded with unneeded capabilities and definitions that are never applied.
General-purpose systems left full
A system installed with default features, roles, and applications carries capabilities no one uses, each a potential entry point. Reducing it to the essential set removes that surface, and leaving it full fails the control.
Essential set defined but not applied
Where the essential capabilities are defined but systems are never reconfigured to match, objective [b] is unmet. The definition has to drive an actual reduction of what systems provide.
Capability creep over time
Even a lean system accumulates capabilities as software and features are added, so without ongoing attention least functionality erodes. Periodic review keeps systems at their essential set.
No definition of essential
Without deciding what is essential, there is no principled basis for removing anything, so systems stay full by default. Defining the essential capabilities is the necessary first step.
4Ownership
This is an IT-owned technical control, and its work is deciding what is essential and configuring systems down to it.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Defines the essential capabilities and configures systems to provide only those, removing the rest. Owns the technical evidence. |
| Security or compliance lead | Confirms the essential set reflects real need and that systems are actually reduced to it. |
| Program lead | Includes least functionality in periodic review as systems accumulate capabilities, and retains the evidence. |
5Tooling
The control is delivered by configuring systems to a lean, essential state and keeping them there.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Defined essential capability set per system type | The basis for deciding what to keep and what to remove. |
| [b] configure | Baseline hardening, role and feature removal | Systems configured to provide only the essential capabilities. |
| [b] maintain | Periodic review, configuration compliance | Keeping systems at the essential set as capabilities would otherwise creep in. |
The caveat is that defining essential capabilities does nothing until systems are reduced to them. The reduction is the work, and it has to be maintained as new capabilities are added. The assessor examines whether systems actually provide only their essential capabilities, so the configuration, not just the definition, has to demonstrate least functionality.
6Evidence
The satisfied version of 3.4.6 shows defined essential capabilities and systems reduced to them.
| Evidence | What it demonstrates |
|---|---|
| Essential capability definition | Objective [a]. The defined essential set based on least functionality. |
| System configuration | Objective [b]. Systems configured to provide only the essential capabilities. |
| Review records | Objective [b]. Evidence systems are kept at the essential set over time. |
The evidence should show that systems provide only their defined essential capabilities, not just that the essentials were listed. The definition paired with configured, maintained systems is the clearest demonstration, and because this control cannot sit on a plan of action, the reduction has to be real at the time of assessment.
Every unused capability is attack surface
A system that does only what it needs is safer than one loaded with unused features, and this five-point control asks for systems reduced to their essential capabilities. Defining what is essential and stripping the rest is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.4.6. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.4.6[a] and 3.4.6[b]. csrc.nist.gov
- 32 CFR 170.24, CMMC Scoring Methodology, listing CM.L2-3.4.6 among the five-point derived security requirements. ecfr.gov