CMMC Level 2 Practice 3.4.6: Employ the principle of least functionality by configuring organizational systems to provide

CMMC Level 2 Practice 3.4.6 requires you to configure systems to run only the functions you need, and to disable, remove, or tightly control everything else. To operationalize it quickly, define “approved functionality” per system, enforce hardened configurations, restrict ports/services/apps, and keep recurring evidence that least functionality is designed, implemented, and maintained. ¹

Key takeaways:

• Define and enforce “allowed functionality” (services, ports, apps, features) for every in-scope system handling CUI. ¹
• Standard builds and configuration management are the fastest path to consistent least functionality across endpoints, servers, and network devices. ¹
• Assessors will look for proof of ongoing control operation (baselines, exceptions, scans, and change records), not just a policy statement. ²

For most CMMC Level 2 programs, “least functionality” is where good intentions go to die: teams have a policy that says “disable unnecessary services,” but they cannot show what “necessary” means for each asset class, how it’s enforced, or how exceptions are controlled. CMMC Level 2 Practice 3.4.6 (mapped to NIST SP 800-171 Rev. 2) is a configuration requirement. It expects you to actively reduce the attack surface of in-scope systems by limiting what systems can do to what the business needs. ¹

If you’re a CCO, compliance officer, or GRC lead, your operational goal is straightforward: make least functionality auditable. That means (1) a defined baseline for each standard build, (2) technical enforcement and monitoring, and (3) exception handling with approvals and compensating controls. You do not need perfection on day one, but you do need a defensible, repeatable process with evidence that you can hand to a CMMC assessor. ²

This page gives requirement-level implementation guidance you can assign to IT and security teams, then verify through artifacts.

Requirement: CMMC Level 2 Practice 3.4.6 (Least Functionality)

Target keyword: cmmc level 2 practice 3.4.6: employ the principle of least functionality by configuring organizational systems to provide requirement

Plain-English interpretation

You must configure systems so they only provide the functions your organization actually needs. “Functions” includes enabled services, open ports, running applications, installed components, default features, and protocols. If you cannot justify it, disable it, remove it, or restrict it. ¹

From an assessment standpoint, least functionality is “configuration hygiene with governance.” The assessor expectation is that you can point to your standard configurations, show how you enforce them, and show how you detect drift and handle exceptions. ²

Regulatory text

The CMMC Level 2 practice is mapped to NIST SP 800-171 Rev. 2 requirement 3.4.6: “Employ the principle of least functionality by configuring organizational systems to provide [only essential capabilities].” ¹
Operationally, you must:

• Identify nonessential functions on in-scope systems.
• Configure systems to disable or restrict those functions.
• Maintain this configuration over time through change control and monitoring so the environment stays hardened, not just “hardened once.” ¹

Who it applies to

Entity scope: Defense contractors and other federal contractors handling Controlled Unclassified Information (CUI) in the performance of contracts that invoke CMMC Level 2 requirements. ³

Operational scope (what assessors will treat as “in scope”):

• Endpoints used to create, access, process, or store CUI.
• Servers and virtual infrastructure hosting CUI workloads.
• Network devices and security tools that protect or route traffic to CUI systems.
• Cloud and SaaS configurations where your organization controls settings that affect enabled features and exposure. ²

If you have a segmented enclave for CUI, least functionality applies at minimum to the enclave assets and any supporting infrastructure required for secure operation. ²

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

Step 1: Define “approved functionality” per system class

Create a short, explicit list for each standard build (example classes: Windows workstations, Linux servers, domain controllers, jump hosts, VPN gateways, firewalls). For each class, define:

• Allowed roles and installed packages/components
• Allowed services/daemons
• Allowed inbound/outbound ports and protocols
• Allowed admin tools and remote management methods
• Allowed browser plugins, scripting engines, and macro settings where relevant ¹

Deliverable: a Least Functionality Baseline per system class that can be mapped to configuration settings.

Step 2: Implement hardened configuration baselines

Turn the approved functionality lists into enforceable configurations:

• Endpoint management policies (e.g., configuration profiles) for workstations
• Server configuration management (gold images, infrastructure-as-code where available)
• Network device standards (router/switch/firewall templates)
• SaaS tenant settings standards (disable unneeded features, restrict integrations) ¹

Practical operator note: writing a baseline that is not technically enforced will fail under scrutiny. Expect the assessor to ask how you prevent re-enablement. ²

Step 3: Disable or remove nonessential services and features

For each system class:

• Remove unused software (including bundled components that are not required)
• Disable unnecessary services (especially legacy protocols and discovery services)
• Close unused ports at host and network layers
• Restrict execution of unauthorized applications (application allowlisting where feasible) ¹

Keep the focus on what you can prove: if you cannot demonstrate the control state, scope it, enforce it, and collect evidence.

Step 4: Control introduction of new functionality through change management

Least functionality breaks when teams “temporarily” enable something and it becomes permanent. Put guardrails in place:

• Require approval to add software, enable services, or open ports on in-scope systems
• Document business justification and security impact
• Time-bound exceptions with review triggers
• Compensating controls for approved exceptions (segmentation, additional monitoring) ¹

Step 5: Monitor configuration drift and remediate

You need an operational loop:

• Detect drift from baselines (configuration scanning, endpoint compliance reporting, firewall rule review)
• Triage drift (authorized change vs. misconfiguration)
• Remediate and record the action (ticket, change record, or exception) ²

Step 6: Prepare the assessment narrative and mapping

Map the practice to a documented control description that ties together:

• Policy intent (least functionality requirement)
• Technical enforcement methods (baselines, tools, responsible teams)
• Evidence cadence (what you collect and how often)
• Exception handling process (who approves, where it’s recorded) ²

If you use Daydream to operationalize this, the most valuable setup is a control record that (1) lists each system class baseline as a required artifact and (2) schedules recurring evidence capture (configuration compliance exports, drift reports, and exception registers) so you are never rebuilding proof at assessment time. ²

Required evidence and artifacts to retain

Keep evidence tied to scope and system classes. Assessors want to see “defined, enforced, and maintained.” ²

Minimum practical evidence set:

• Least Functionality Policy/Standard describing intent, scope, and responsibility. ¹
• System class configuration baselines (gold image specs, hardening checklists, configuration profiles, firewall templates). ¹
• Configuration enforcement proof (screenshots/exports from endpoint management, configuration management commits, device configs). ²
• Exception register with approvals, justification, compensating controls, and closure criteria. ¹
• Change records/tickets showing controlled enablement of new services/apps/ports for in-scope assets. ¹
• Drift/compliance reports and remediation tickets showing ongoing maintenance. ²

Common exam/audit questions and hangups

Expect these questions in a CMMC Level 2 assessment context. ²

1. “Show me your standard configuration for an in-scope workstation/server.”
   Hangup: You have a policy but no baseline artifact.

2. “How do you know unnecessary services are disabled across the environment?”
   Hangup: You can show one host, not coverage across in-scope assets.

3. “What happens when engineering needs a new tool or port opened?”
   Hangup: No documented exception/change process; changes happen ad hoc.

4. “How do you prevent drift?”
   Hangup: No monitoring or periodic validation evidence.

5. “What is in scope for least functionality?”
   Hangup: Asset inventory and boundary definitions are unclear, so least functionality becomes subjective. ²

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Treating least functionality as “disable a few Windows services”

Avoidance: Make it a per-system-class baseline plus enforcement, covering apps, ports, protocols, and features that expand exposure. ¹

Mistake 2: No exception path, so teams bypass you

Avoidance: Provide a fast exception workflow with required fields (business need, scope, duration/conditions, compensating controls) and track it. ¹

Mistake 3: Baselines exist, but endpoints are not consistently enrolled

Avoidance: Tie least functionality evidence to the list of in-scope assets and show enrollment/compliance reporting for that population. ²

Mistake 4: Firewall rules sprawl with no ownership

Avoidance: Assign rule owners, require justification, and periodically review rules tied to CUI flows and system baselines. Keep records. ¹

Mistake 5: “One-and-done” hardening with no drift monitoring

Avoidance: Collect recurring configuration compliance evidence and remediation records. This is where Daydream-style recurring evidence capture prevents last-minute scrambles. ²

Enforcement context and risk implications

No specific public enforcement cases are provided in the supplied source catalog for this practice. What you can assume safely: CMMC Level 2 is an assessable requirement set under the CMMC Program rule, and failure to implement or to produce evidence can affect certification outcomes tied to contract eligibility. ⁴

From a security perspective, excess functionality increases your attack surface: more exposed services, more patching demand, and more avenues for lateral movement. Least functionality is a practical control that reduces that exposure when applied consistently. ¹

Practical 30/60/90-day execution plan

A staged plan is helpful, but fixed day counts are not source-backed here. Use the phases below as execution windows and size them to your environment.

Immediate phase: establish scope and baselines

• Confirm the in-scope system population for CUI (endpoints, servers, network/security devices, cloud tenants). ²
• Draft least functionality standards and “approved functionality” lists for your highest-volume system classes. ¹
• Stand up an exception register and a change gate for enabling new services/apps/ports on in-scope assets. ¹

Near-term phase: enforce and measure

• Convert baselines into technical enforcement (endpoint profiles, server build standards, network templates). ¹
• Run a drift assessment against in-scope assets; open remediation work items. ²
• Start recurring evidence capture: baseline documents, compliance exports, drift findings, and resolved tickets. ²

Ongoing phase: operationalize as BAU

• Integrate least functionality checks into provisioning (new build) and change management. ¹
• Review exceptions and remove temporary enablements that are no longer needed. ¹
• Maintain an assessment-ready package in your GRC system (Daydream or equivalent): narratives, artifacts, and recurring evidence. ²

Frequently Asked Questions

Does least functionality mean I must remove all software not strictly required for CUI?

It means you must define what is approved for in-scope systems and restrict everything else through configuration and control. If nonessential software remains installed, you need a justification and controls that prevent it from increasing exposure. ¹

Can I meet 3.4.6 with policy only?

A policy helps, but CMMC assessments typically expect proof of implementation and ongoing operation, such as baselines, enforcement settings, and drift evidence. Plan for technical artifacts, not just written statements. ²

What’s the fastest evidence an assessor will accept?

Provide (1) a baseline for a defined system class, (2) an export or screenshot showing it is enforced on in-scope assets, and (3) tickets/records showing you correct drift and control exceptions. ²

How do we handle engineering tools that require elevated features or open ports?

Route requests through an exception and change workflow with documented justification and compensating controls, then track and periodically review the exception for closure. Keep the record tied to specific assets and dates. ¹

Does this apply to SaaS and cloud services?

Yes if the SaaS or cloud service is part of the in-scope environment and you control configuration settings that affect enabled features, exposure, or integrations. Capture tenant settings baselines and evidence of enforcement. ¹

How do I show “least functionality” for network devices?

Maintain approved configuration templates (services enabled, management access methods, allowed ports/protocols) and keep running-config evidence plus change records for deviations. Pair that with periodic reviews for rules/services tied to CUI flows. ¹

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170

4. 32 CFR Part 170; Source: DoD CMMC Program Guidance