CM-7: Least Functionality

Quick-reference card

What this control requires

CM-07 requires organizations to configure systems so they provide only mission-essential capabilities and restrict everything else. That means every function, port, protocol, piece of software, and service running on a system needs a documented reason to exist. Anything without one should be disabled or removed.

But the practical scope is broader than it sounds. Most operating systems and enterprise applications ship with dozens of features enabled by default, many of which never get used. CM-07 treats those defaults as risk until proven otherwise. Organizations need to define what’s mission-essential, lock down what isn’t, and maintain that posture as systems change over time.

In practice, this control sits at the core of the National Institute of Standards and Technology (NIST) SP 800-53 configuration management family, and it works best when paired with strong baseline configurations and ongoing monitoring. The goal isn’t just compliance documentation. It’s reducing the attack surface to the smallest footprint that still lets the organization operate.

The configuration management family encompasses related controls that define and enforce approved configurations across system components. A solid approach to configuration management makes least functionality achievable at scale.

Why it matters

Every unnecessary service running on a system is an invitation that attackers don’t need a second chance to accept. When organizations fail to restrict system functionality to what’s essential, they create entry points that persist month after month, invisible to teams focused on patching and perimeter defenses.

The consequences aren’t theoretical. Unused ports and protocols represent some of the most exploited vectors in modern breaches, precisely because they’re forgotten and sit outside routine vulnerability scanning processes. Security teams often invest heavily in endpoint detection and vulnerability scanning while leaving legacy services enabled across thousands of hosts.

WannaCry ransomware and the NHS

On May 12, 2017, the WannaCry ransomware began spreading globally by exploiting EternalBlue, a vulnerability in the Server Message Block version 1 (SMBv1) protocol. Microsoft had released patch MS17-010 on March 14, 2017.

The deeper failure, though, wasn’t about patching speed. Microsoft had deprecated SMBv1 in 2014 and recommended disabling it in 2016. Organizations that had followed least functionality principles and turned off the unnecessary protocol were immune to WannaCry regardless of whether they’d applied the patch.

The result was devastating. WannaCry affected approximately 80 National Health Service (NHS) organizations, including 34 acute trusts, and forced the cancellation of around 19,000 appointments. The UK National Audit Office estimated the cost at £92 million in direct cleanup and lost productivity. A killswitch discovered by an independent researcher limited wider damage, but the root cause remained clear: unnecessary services left enabled on production systems.

In practice, the National Cyber Security Centre’s guidance on WannaCry reinforces exactly what CM-07 has always required. Disabling services you don’t need isn’t a nice-to-have optimization. It’s a direct control against exploitation.

What attackers exploit when least functionality fails:

• Unused network protocols and ports that provide lateral movement paths across segmented environments
• Default services and administrative tools that ship enabled on operating systems and middleware
• Legacy software components left installed after migrations or upgrades
• Development and debugging utilities that persist on production systems
• Unnecessary remote access services that expand the attack surface through misconfigurations

How to implement

Most organizations don’t fail CM-07 at initial hardening. They fail at drift, as configurations loosen over time and exceptions accumulate without expiration dates.

For your organization

Start with a complete inventory of every function, service, port, and protocol active across your systems. You can’t restrict what you haven’t mapped. Automated discovery tools and network scanning should supplement manual documentation, since configuration drift means yesterday’s inventory is already outdated.

Specifically, each system component needs a baseline of mission-essential capabilities. Work with system owners to define what each host actually needs to operate. Where feasible, limit each component to a single function. A server that handles both web traffic and database queries has twice the attack surface of two dedicated hosts.

The next step is removing everything that falls outside those mission-essential boundaries. This includes unused ports, protocols, default services, sample applications, and administrative utilities that aren’t actively required. Don’t overlook middleware and application-layer defaults that ship enabled but never get configured for production use.

In practice, enforcement requires layered tooling. Application whitelisting tools can restrict which software runs on each host, while endpoint detection platforms can flag unauthorized services or unexpected process launches. Network scanning tools can validate that only approved ports remain open from the outside in.

Where this breaks down is ongoing maintenance. Build a recurring review cycle tied to your change management process. Quarterly reviews of active services against your approved baseline catch drift before it becomes exposure.

Specifically, the same discipline applies to new deployments. Every change request that introduces a new service or opens a port should trigger a least functionality assessment before approval. This prevents new deployments from quietly re-introducing functionality that was previously restricted.

Documentation is where auditors focus their evidence review. For every function you leave enabled, record the business justification, the system owner who approved it, and the review date. This serves double duty: it satisfies auditor evidence requests and gives your team a clear reference when configurations are questioned during incident response.

Common mistakes to avoid:

• Inventorying services once and treating it as a permanent record
• Allowing exceptions without documented expiration dates
• Relying solely on host-based controls without network-level validation
• Excluding development and staging environments from least functionality requirements
• Treating initial hardening as a one-time project rather than a continuous process

For your vendors

When assessing third-party compliance with CM-07, your questionnaires should go beyond “do you restrict unnecessary services?” and probe for specifics. Ask vendors to describe their process for identifying mission-essential capabilities on systems that handle your data. Request their baseline configuration standards and how often they review active services against those baselines.

Specifically, strong questionnaire questions include: “What is your process for disabling unnecessary ports, protocols, and services on systems in scope?” and “How do you maintain and enforce an approved software list?” Vendors should also be able to explain how they handle exceptions and what triggers a review of their active service inventory.

Specifically, the evidence you request should go beyond policy documents. Ask for configuration management policies, system hardening standards, and sample outputs from automated configuration scanning.

Vendors should be able to demonstrate that they maintain an approved list of software and services, and that they have a documented process for disabling or removing unauthorized components. Independent System and Organization Controls 2 Type II audit reports that reference configuration management controls provide stronger assurance than self-attestation alone.

Where this breaks down is in vague responses. Watch for references to “industry best practices” without naming specific frameworks, an inability to produce configuration baselines for systems in scope, or no evidence of periodic review.

Vendors who can’t articulate what’s running on their systems likely aren’t restricting it either. Another warning sign is when hardening documentation hasn’t been updated in over a year, suggesting the vendor treats least functionality as a one-time exercise.

In practice, verification should combine document review with technical evidence. Ask for screenshots or exports from configuration management tools showing enforced baselines. Review their change management logs for evidence that new deployments go through a least functionality review. For critical vendors, consider requesting results from independent assessments that validate their NIST 800-53 controls.

Evidence examples

Cross-framework mapping

Related controls

• AC-03 — Access Enforcement — Enforces authorization decisions that complement least functionality by ensuring users can only access the capabilities that remain after unnecessary functions are removed.
• AC-04 — Information Flow Enforcement — Controls how information moves between system components, reinforcing CM-07 by restricting data flows through only the ports and protocols deemed mission-essential.
• CM-02 — Baseline Configuration — Establishes the approved system configuration that CM-07 builds upon, defining the starting point from which unnecessary functions are identified and removed.
• CM-05 — Access Restrictions for Change — Limits who can modify system configurations, preventing unauthorized re-enablement of functions, services, or software that CM-07 has restricted.
• CM-06 — Configuration Settings — Defines and enforces specific parameter values within system components, supporting CM-07 by ensuring that approved services operate under hardened settings.
• CM-11 — User-installed Software — Restricts what users can install on organizational systems, directly supporting least functionality by preventing unauthorized software from expanding the attack surface.
• RA-05 — Vulnerability Monitoring and Scanning — Identifies security weaknesses in active system components, helping organizations detect when unnecessary services or software introduce exploitable vulnerabilities.
• SA-04 — Acquisition Process — Integrates security requirements into procurement, ensuring that new systems and components arrive configured for least functionality rather than requiring post-deployment hardening.
• SA-05 — System Documentation — Provides the technical references needed to understand system capabilities and identify which functions are mission-essential versus unnecessary.
• SA-08 — Security and Privacy Engineering Principles — Embeds least functionality into system design from the start, reducing the need for retroactive removal of unnecessary components.

Frequently asked questions

What is NIST SP 800-53 CM-07?

CM-07 is the NIST SP 800-53 control that mandates least functionality across all system components. It applies at all three baselines (LOW, MODERATE, HIGH) and requires organizations to define mission-essential capabilities, then prohibit or restrict every function, port, protocol, piece of software, and service that falls outside that scope. The distinguishing requirement is documentation: every active component must have an operational justification on record, separating CM-07 from informal hardening practices.

What happens if CM-07 is not implemented?

Failure to implement CM-07 leaves unnecessary services, ports, and protocols active on production systems, each representing a potential entry point for attackers. The WannaCry incident demonstrated this directly: organizations that had disabled the deprecated SMBv1 protocol were unaffected, while those running the unnecessary service suffered ransomware infections even when patches were available. Without least functionality controls, organizations also face audit findings, increased remediation costs, and difficulty demonstrating compliance to regulators and business partners.

How do you audit CM-07?

Auditing CM-07 involves verifying that the organization has defined mission-essential capabilities for each system, and that all active functions, ports, protocols, software, and services are documented and justified. Auditors typically review configuration management policies, examine system component inventories, and compare running configurations against approved baselines.

Automated scanning tools can validate that only authorized services remain active. The assessment should also confirm that technical controls actively enforce the prohibited or restricted functions list, not just document them in policy.

What is the difference between least functionality and least privilege?

Least functionality (CM-07) restricts what a system can do by disabling unnecessary services, ports, protocols, and software. Least privilege (AC-06) restricts what a user or process can do by limiting permissions to the minimum required for their role.

They complement each other: CM-07 reduces the system’s overall capability set, while AC-06 ensures that the capabilities that remain are only accessible to authorized subjects. Both controls are essential for minimizing attack surface, but they operate at different layers of the security architecture.