CM-7: Least Functionality

The cm-7: least functionality requirement is one of the fastest ways to reduce attack surface without buying new tools. Auditors and assessors look for a simple story: you know what “normal” looks like for each platform, you can prove you hardened it to that standard, and you can show that anything outside the standard is a controlled exception.

Operationally, CM-7 usually fails for one of three reasons. First, teams confuse “hardening guidance exists” with “hardening is enforced.” Second, the organization can’t show an authoritative inventory of what is enabled, so least functionality becomes an opinion. Third, exceptions are granted casually (or permanently) with no revalidation, creating a quiet backlog of risky exposure.

This page gives requirement-level implementation guidance for a Compliance Officer, CCO, or GRC lead: who must comply, what to implement, how to run it as an operating control, and what evidence to retain so you can answer assessor questions without a scramble. It also includes a practical execution plan you can hand to infrastructure and application owners.

Regulatory text

Excerpt (CM-7): “Configure the system to provide only {{ insert: param, cm-07_odp.01 }} ; and” ¹

Operator meaning: You must configure systems so they only provide the functions needed for business purpose and security requirements, and you must actively disable, remove, or restrict everything else. “Least functionality” is not a policy statement. It is a configuration outcome you can demonstrate on real assets through settings, build standards, and monitoring ².

Plain-English interpretation (what CM-7 expects)

CM-7 expects you to:

• Define what “minimum necessary functionality” means for each system class (workstations, servers, containers, network devices, cloud services, SaaS admin consoles).
• Configure systems to match that minimum by disabling or removing nonessential capabilities (example categories: services/daemons, unused packages, open ports, protocols, drivers, browser plugins, admin tools, default accounts, sample apps).
• Control and document exceptions when a nonessential function must remain enabled for a justified business reason.
• Sustain the state over time by detecting and correcting configuration drift.

If you can’t state (a) what should be enabled, (b) what is actually enabled, and (c) how you handle deviations, you will struggle to defend CM-7 in an assessment.

Who it applies to (entity and operational context)

CM-7 is relevant wherever you apply NIST SP 800-53 to a system boundary, including:

• Federal information systems.
• Contractor systems handling federal data ¹.

In practice, the control applies across:

• Infrastructure: endpoints, servers, VM images, container base images, managed databases, network/security appliances.
• Platforms and cloud: IaaS/PaaS configurations (security groups, firewall rules, admin APIs, storage features, identity features).
• Applications: deployed components and features (debug endpoints, admin consoles, unused modules).
• Third parties: hosted platforms and managed services when you control configuration or can require secure configuration through contract and due diligence. If a third party’s product includes optional features, CM-7 maps to your obligation to disable what you do not need, or to document why it must remain enabled.

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

1) Create a CM-7 control card (make ownership and scope unambiguous)

Write a one-page “control card” that an operator can run without interpretation:

• Objective: enforce least functionality across in-scope systems.
• Owner: named role (not a committee).
• In-scope assets: by environment/system class.
• Trigger events: new build, major version change, new third party integration, exception request, security incident learnings.
• Cadence: ongoing monitoring and periodic review appropriate to your environment.
• Exception rules: who can approve, required justification, how long exceptions can last, and when they must be revalidated.

This aligns directly with the operational risk factor that teams cannot show who owns the requirement or what evidence proves it runs ¹.

2) Define “minimum functionality” baselines per system type

Create a baseline per platform class. Keep it concrete:

• Allowed services/daemons and required startup mode.
• Allowed open ports and listening interfaces.
• Allowed protocols and ciphers (where applicable).
• Allowed installed packages (or explicitly disallowed packages).
• Allowed privileged tools (remote admin, scripting engines, compilers) based on role.
• Configuration settings for key security features (logging on, debug off, remote management restricted).

Tip: Build baselines from what you run in production, not an aspirational document. You can tighten iteratively.

3) Implement the baseline as code (so it’s enforced, not remembered)

Pick the enforcement mechanism your environment already supports:

• Golden images (endpoint/server images) with only required components installed.
• Configuration management to disable services, remove packages, and set system parameters.
• Container base images that are minimal and pinned; remove build tools from runtime images.
• Cloud policy controls (where available) to prevent enabling non-approved features.
• SaaS configuration standards for admin settings and feature toggles.

Your compliance deliverable is that a system build or deployment results in least functionality by default, and changes are controlled.

4) Measure actual state and detect drift

Baselines without drift detection fail quickly. Implement a way to answer:

• Which hosts have non-approved packages installed?
• Which services are running that should be disabled?
• Which ports are open outside the standard?
• Which cloud resources have risky features enabled?

Operational approach:

• Run routine configuration checks and log exceptions into a remediation queue.
• Track each deviation to closure, with validation that the setting changed or the exception is formally approved.

This connects to the recommended practice of recurring control health checks with remediation tracked to validated closure ¹.

5) Create an exception workflow that is strict but usable

Least functionality always meets edge cases. Your workflow should require:

• Business justification and system owner sign-off.
• Security review with compensating controls if needed.
• Scope boundaries (which systems, which ports/services/features, which environments).
• Expiration or revalidation trigger tied to change management.

A practical rule: if you can’t articulate the function’s purpose, you should disable it.

6) Prove it runs: define the evidence bundle (minimum viable and consistent)

Define what evidence you will collect every cycle so audits stop turning into archaeology. Minimum bundle:

• Baseline standard for each system class.
• Output of configuration scans/checks showing pass/fail against baseline.
• List of deviations, tickets, and closure evidence (before/after, approval notes).
• Exception register with current status.
• Change records for baseline updates.

This maps to the recommended practice of defining the minimum evidence bundle ¹.

Required evidence and artifacts to retain

Use this as an assessor-ready checklist:

Governance artifacts

• CM-7 control card: scope, owner, triggers, exception rules.
• System security plan or configuration standard referencing CM-7 control implementation (if you maintain SSP-style documentation).

Technical artifacts

• Configuration baselines per system type (versioned).
• Hardened image definitions (golden image specs, IaC modules, configuration scripts).
• Drift detection outputs (scan reports, dashboards, or exported results).
• Proof of disabled/removed components (config excerpts, command outputs, policy settings).

Operational artifacts

• Exception register with approvals and revalidation outcomes.
• Remediation tickets with validation notes.
• Control health check records (what was checked, by whom/what, and results).

Retention location matters. Auditors expect you to produce evidence quickly and consistently, not reconstruct it from individual engineers’ laptops.

Common exam/audit questions and hangups

Expect these and prepare short, evidence-backed answers:

1. “Show me your baseline for this server type, and show me this host conforms.”
   Hangup: teams have a PDF baseline but no host-level evidence.

2. “How do you prevent re-enabling disabled functionality?”
   Hangup: one-time hardening with no drift detection.

3. “What’s your exception process, and how many active exceptions exist?”
   Hangup: informal approvals in chat with no register.

4. “How do you handle least functionality in cloud-managed services?”
   Hangup: unclear responsibility split between you and the cloud provider/third party.

5. “Who owns CM-7 operationally?”
   Hangup: ownership is “Security” in general, with no accountable operator.

Frequent implementation mistakes and how to avoid them

• Mistake: “We don’t use that service” instead of disabling it.
  Fix: require explicit disable/remove actions in the baseline, then verify state with scans.

• Mistake: Baselines that are too generic to test.
  Fix: make baselines machine-checkable (allowed ports, package lists, service states).

• Mistake: Exceptions become permanent.
  Fix: require revalidation on meaningful triggers (system changes, major upgrades, incident learnings) and maintain an exception register with owners.

• Mistake: CM-7 treated as only an OS hardening control.
  Fix: include application features (debug modes, admin endpoints), cloud feature toggles, and SaaS settings in scope.

• Mistake: Evidence is scattered.
  Fix: define the evidence bundle and a single retention location so you can produce proof on demand ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CM-7, so this page does not list specific cases. Practically, least functionality ties directly to breach pathways assessors recognize: unnecessary exposed services, default features, and ungoverned administrative interfaces. If you can’t demonstrate least functionality, the risk is straightforward: larger attack surface, more misconfiguration routes, and weaker defensibility in customer and government assessments ³.

Practical 30/60/90-day execution plan

Use phases rather than calendar promises. The goal is fast coverage on high-risk systems first, then expand.

Immediate (stabilize and define)

• Name a CM-7 owner and publish the CM-7 control card.
• Confirm in-scope system classes and environments.
• Draft initial baselines for the most critical system class (production servers or identity/admin systems).
• Stand up an exception register and require it for any deviation found.

Near-term (enforce and measure)

• Convert baseline into enforceable build standards (images, IaC, configuration management).
• Start drift detection on the first system class; create a remediation workflow.
• Run the first control health check cycle; capture the full evidence bundle end-to-end ¹.

Ongoing (expand and mature)

• Expand baselines to remaining system classes, including cloud services and SaaS admin configurations.
• Tighten exception handling: revalidation triggers, compensating controls, and reporting to risk governance.
• Add routine reporting: top deviation types, time-to-close, and recurring root causes to drive engineering fixes.

Where Daydream fits (without changing your stack): Daydream is useful when you need CM-7 to operate like a control, not a document: a control card template, an evidence bundle definition per cycle, and recurring health checks with tracked remediation help you answer audits with consistent artifacts instead of ad hoc exports ¹.

Frequently Asked Questions

Does CM-7 require uninstalling software, or is disabling enough?

CM-7 expects least functionality as a configuration outcome. If a component increases attack surface, removing it is often cleaner than disabling it, but you can justify disable-only with an exception and compensating controls documented against the baseline ¹.

How do we apply CM-7 to cloud services where we can’t see the underlying OS?

Treat “functionality” as cloud configuration features you control: network exposure, admin APIs, optional service features, logging settings, and identity integrations. Your baseline becomes a secure configuration standard for that service, plus drift checks against those settings ³.

What’s the minimum we need to show an auditor for CM-7?

Show (1) a baseline, (2) evidence that systems are configured to that baseline, and (3) an exception register with approvals and current status. Add drift detection output and remediation closure records to demonstrate sustained operation ¹.

Can application feature flags and debug endpoints fall under CM-7?

Yes. “Least functionality” includes disabling nonessential application components and features, especially administrative or diagnostic functions that expand exposure. Treat them like any other nonessential function: baseline, verify, and control exceptions ³.

How do we handle third parties under CM-7?

If you can configure the third party service, apply your baseline to those settings and retain evidence (screenshots/exports and change records). If you cannot configure it, address least functionality in due diligence and contracting by requiring secure default configurations, change notification, and administrative control limitations ³.

Who should own CM-7: Security, IT, or Engineering?

Assign a single accountable owner who can enforce build standards and drive remediation, usually Infrastructure/Platform with Security oversight. Auditors care less about org chart and more about clear ownership, operating cadence, and retained evidence ¹.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5