Control statement
- a.Configure the system to provide only [Organization-defined: mission-essential capabilities] ; and
- b.Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: [Organization-defined: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services].
Discussion
Systems provide a wide variety of functions and services. Some of the functions and services routinely provided by default may not be necessary to support essential organizational missions, functions, or operations. Additionally, it is sometimes convenient to provide multiple services from a single system component, but doing so increases risk over limiting the services provided by that single component. Where feasible, organizations limit component functionality to a single function per component. Organizations consider removing unused or unnecessary software and disabling unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of components, transfer of information, and tunneling. Organizations employ network scanning tools, intrusion detection and prevention systems, and end-point protection technologies, such as firewalls and host-based intrusion detection systems, to identify and prevent the use of prohibited functions, protocols, ports, and services. Least functionality can also be achieved as part of the fundamental design and development of the system (see [SA-8](#sa-8), [SC-2](#sc-2) , and [SC-3](#sc-3)).
Organization-defined parameters
These values must be resolved through the organization’s tailoring and governance process. Bracketed parameter references in the control text identify where a decision is required.
From control text to operational evidence
Use Least Functionality as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to secure baselines, controlled change, configuration visibility, and drift management.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- approved baseline configurations
- change tickets and approvals
- configuration scans and drift reports
- software and hardware inventories
Common failure patterns
- baselines documented but not enforced
- emergency changes never reconciled
- asset inventories that omit cloud or ephemeral resources
- security-impact analysis performed after deployment
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
- CM-07a.the system is configured to provide only [Organization-defined: mission-essential capabilities];
- CM-07b.
- CM-07b.[01]the use of [Organization-defined: functions] is prohibited or restricted;
- CM-07b.[02]the use of [Organization-defined: ports] is prohibited or restricted;
- CM-07b.[03]the use of [Organization-defined: protocols] is prohibited or restricted;
- CM-07b.[04]the use of [Organization-defined: software] is prohibited or restricted;
- CM-07b.[05]the use of [Organization-defined: services] is prohibited or restricted.
Examine
- Configuration management policy
- procedures addressing least functionality in the system
- configuration management plan
- system design documentation
- system configuration settings and associated documentation
- system component inventory
- common secure configuration checklists
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with security configuration management responsibilities
- organizational personnel with information security responsibilities
- system/network administrators
- system developers
Test
- Organizational processes prohibiting or restricting functions, ports, protocols, software, and/or services
- mechanisms implementing restrictions or prohibition of functions, ports, protocols, software, and/or services
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Related NIST SP 800-171 requirements
These Rev. 3 requirements cite this base control or one of its enhancements as a source. The relationship does not by itself determine contractual applicability or complete implementation.
Control enhancements
Enhancements add specificity, strength, or scope to the base control. Baseline badges show explicit selections in the official SP 800-53B OSCAL profiles.
CM-7(1) — Periodic Review
- (a)Review the system [Organization-defined: frequency] to identify unnecessary and/or nonsecure functions, ports, protocols, software, and services; and
- (b)Disable or remove [Organization-defined: organization-defined functions, ports, protocols, software, and services within the system deemed to be unnecessary and/or nonsecure].
Official discussion
Organizations review functions, ports, protocols, and services provided by systems or system components to determine the functions and services that are candidates for elimination. Such reviews are especially important during transition periods from older technologies to newer technologies (e.g., transition from IPv4 to IPv6). These technology transitions may require implementing the older and newer technologies simultaneously during the transition period and returning to minimum essential functions, ports, protocols, and services at the earliest opportunity. Organizations can either decide the relative security of the function, port, protocol, and/or service or base the security decision on the assessment of other entities. Unsecure protocols include Bluetooth, FTP, and peer-to-peer networking.
Organization-defined parameters (7)
Assessment objectives and methods
- CM-07(01)(a)the system is reviewed [Organization-defined: frequency] to identify unnecessary and/or non-secure functions, ports, protocols, software, and services:
- CM-07(01)(b)
- CM-07(01)(b)[01][Organization-defined: functions] deemed to be unnecessary and/or non-secure are disabled or removed;
- CM-07(01)(b)[02][Organization-defined: ports] deemed to be unnecessary and/or non-secure are disabled or removed;
- CM-07(01)(b)[03][Organization-defined: protocols] deemed to be unnecessary and/or non-secure are disabled or removed;
- CM-07(01)(b)[04][Organization-defined: software] deemed to be unnecessary and/or non-secure is disabled or removed;
- CM-07(01)(b)[05][Organization-defined: services] deemed to be unnecessary and/or non-secure are disabled or removed.
Examine
- Configuration management policy
- procedures addressing least functionality in the system
- configuration management plan
- system design documentation
- system configuration settings and associated documentation
- common secure configuration checklists
- documented reviews of functions, ports, protocols, and/or services
- change control records
- system audit records
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with responsibilities for reviewing functions, ports, protocols, and services on the system
- organizational personnel with information security responsibilities
- system/network administrators
- system developers
Test
- Organizational processes for reviewing or disabling functions, ports, protocols, and services on the system
- mechanisms implementing review and disabling of functions, ports, protocols, and/or services
Related controls
CM-7(2) — Prevent Program Execution
Prevent program execution in accordance with [Organization-defined: cm-07.02_odp.01].
Official discussion
Prevention of program execution addresses organizational policies, rules of behavior, and/or access agreements that restrict software usage and the terms and conditions imposed by the developer or manufacturer, including software licensing and copyrights. Restrictions include prohibiting auto-execute features, restricting roles allowed to approve program execution, permitting or prohibiting specific software programs, or restricting the number of program instances executed at the same time.
Organization-defined parameters (2)
Assessment objectives and methods
program execution is prevented in accordance with [Organization-defined: cm-07.02_odp.01].
Examine
- Configuration management policy
- procedures addressing least functionality in the system
- configuration management plan
- system design documentation
- system configuration settings and associated documentation
- system component inventory
- common secure configuration checklists
- specifications for preventing software program execution
- change control records
- system audit records
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with information security responsibilities
- system/network administrators
- system developers
Test
- Organizational processes preventing program execution on the system
- organizational processes for software program usage and restrictions
- mechanisms preventing program execution on the system
- mechanisms supporting and/or implementing software program usage and restrictions
Related controls
CM-7(3) — Registration Compliance
Ensure compliance with [Organization-defined: registration requirements].
Official discussion
Organizations use the registration process to manage, track, and provide oversight for systems and implemented functions, ports, protocols, and services.
Organization-defined parameters (1)
Assessment objectives and methods
[Organization-defined: registration requirements] are complied with.
Examine
- System security plan
- configuration management policy
- procedures addressing least functionality in the system
- configuration management plan
- system configuration settings and associated documentation
- system component inventory
- audit and compliance reviews
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with security responsibilities
- system/network administrators
- system developers
Test
- Organizational processes ensuring compliance with registration requirements for functions, ports, protocols, and/or services
- mechanisms implementing compliance with registration requirements for functions, ports, protocols, and/or services
CM-7(4) — Unauthorized Software — Deny-by-exception
- (a)Identify [Organization-defined: software programs];
- (b)Employ an allow-all, deny-by-exception policy to prohibit the execution of unauthorized software programs on the system; and
- (c)Review and update the list of unauthorized software programs [Organization-defined: frequency].
Official discussion
Unauthorized software programs can be limited to specific versions or from a specific source. The concept of prohibiting the execution of unauthorized software may also be applied to user actions, system ports and protocols, IP addresses/ranges, websites, and MAC addresses.
Organization-defined parameters (2)
Assessment objectives and methods
- CM-07(04)(a)[Organization-defined: software programs] are identified;
- CM-07(04)(b)an allow-all, deny-by-exception policy is employed to prohibit the execution of unauthorized software programs on the system;
- CM-07(04)(c)the list of unauthorized software programs is reviewed and updated [Organization-defined: frequency].
Examine
- Configuration management policy
- procedures addressing least functionality in the system
- configuration management plan
- system design documentation
- system configuration settings and associated documentation
- list of software programs not authorized to execute on the system
- system component inventory
- common secure configuration checklists
- review and update records associated with list of unauthorized software programs
- change control records
- system audit records
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with responsibilities for identifying software not authorized to execute on the system
- organizational personnel with information security responsibilities
- system/network administrators
Test
- Organizational process for identifying, reviewing, and updating programs not authorized to execute on the system
- organizational process for implementing unauthorized software policy
- mechanisms supporting and/or implementing unauthorized software policy
Related controls
CM-7(5) — Authorized Software — Allow-by-exception
- (a)Identify [Organization-defined: software programs];
- (b)Employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the system; and
- (c)Review and update the list of authorized software programs [Organization-defined: frequency].
Official discussion
Authorized software programs can be limited to specific versions or from a specific source. To facilitate a comprehensive authorized software process and increase the strength of protection for attacks that bypass application level authorized software, software programs may be decomposed into and monitored at different levels of detail. These levels include applications, application programming interfaces, application modules, scripts, system processes, system services, kernel functions, registries, drivers, and dynamic link libraries. The concept of permitting the execution of authorized software may also be applied to user actions, system ports and protocols, IP addresses/ranges, websites, and MAC addresses. Organizations consider verifying the integrity of authorized software programs using digital signatures, cryptographic checksums, or hash functions. Verification of authorized software can occur either prior to execution or at system startup. The identification of authorized URLs for websites is addressed in [CA-3(5)](#ca-3.5) and [SC-7](#sc-7).
Organization-defined parameters (2)
Assessment objectives and methods
- CM-07(05)(a)[Organization-defined: software programs] are identified;
- CM-07(05)(b)a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the system is employed;
- CM-07(05)(c)the list of authorized software programs is reviewed and updated [Organization-defined: frequency].
Examine
- Configuration management policy
- procedures addressing least functionality in the system
- configuration management plan
- system design documentation
- system configuration settings and associated documentation
- list of software programs authorized to execute on the system
- system component inventory
- common secure configuration checklists
- review and update records associated with list of authorized software programs
- change control records
- system audit records
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with responsibilities for identifying software authorized to execute on the system
- organizational personnel with information security responsibilities
- system/network administrators
Test
- Organizational process for identifying, reviewing, and updating programs authorized to execute on the system
- organizational process for implementing authorized software policy
- mechanisms supporting and/or implementing authorized software policy
Related controls
CM-7(6) — Confined Environments with Limited Privileges
Require that the following user-installed software execute in a confined physical or virtual machine environment with limited privileges: [Organization-defined: user-installed software].
Official discussion
Organizations identify software that may be of concern regarding its origin or potential for containing malicious code. For this type of software, user installations occur in confined environments of operation to limit or contain damage from malicious code that may be executed.
Organization-defined parameters (1)
Assessment objectives and methods
[Organization-defined: user-installed software] is required to be executed in a confined physical or virtual machine environment with limited privileges.
Examine
- Configuration management policy
- procedures addressing least functionality in the system
- configuration management plan
- system design documentation
- system configuration settings and associated documentation
- list or record of software required to execute in a confined environment
- system component inventory
- common secure configuration checklists
- system audit records
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with responsibilities for identifying and/or managing user-installed software and associated privileges
- organizational personnel with information security responsibilities
- system/network administrators
Test
- Organizational process for identifying user-installed software required to execute in a confined environment
- mechanisms supporting and/or implementing the confinement of user-installed software to physical or virtual machine environments
- mechanisms supporting and/or implementing privilege limitations on user-installed software
Related controls
CM-7(7) — Code Execution in Protected Environments
Allow execution of binary or machine-executable code only in confined physical or virtual machine environments and with the explicit approval of [Organization-defined: personnel or roles] when such code is:
- (a)Obtained from sources with limited or no warranty; and/or
- (b)Without the provision of source code.
Official discussion
Code execution in protected environments applies to all sources of binary or machine-executable code, including commercial software and firmware and open-source software.
Organization-defined parameters (1)
Assessment objectives and methods
the execution of binary or machine-executable code is only allowed in confined physical or virtual machine environments;
- CM-07(07)(a)the execution of binary or machine-executable code obtained from sources with limited or no warranty is only allowed with the explicit approval of [Organization-defined: personnel or roles];
- CM-07(07)(b)the execution of binary or machine-executable code without the provision of source code is only allowed with the explicit approval of [Organization-defined: personnel or roles].
Examine
- Configuration management policy
- procedures addressing least functionality in the system
- configuration management plan
- system design documentation
- system configuration settings and associated documentation
- list or record of binary or machine-executable code
- system component inventory
- common secure configuration checklists
- system audit records
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with responsibilities for approving execution of binary or machine-executable code
- organizational personnel with information security responsibilities
- organizational personnel with software management responsibilities
- system/network administrators
- system developers
Test
- Organizational process for approving execution of binary or machine-executable code
- organizational process for confining binary or machine-executable code to physical or virtual machine environments
- mechanisms supporting and/or implementing the confinement of binary or machine-executable code to physical or virtual machine environments
Related controls
CM-7(8) — Binary or Machine Executable Code
- (a)Prohibit the use of binary or machine-executable code from sources with limited or no warranty or without the provision of source code; and
- (b)Allow exceptions only for compelling mission or operational requirements and with the approval of the authorizing official.
Official discussion
Binary or machine executable code applies to all sources of binary or machine-executable code, including commercial software and firmware and open-source software. Organizations assess software products without accompanying source code or from sources with limited or no warranty for potential security impacts. The assessments address the fact that software products without the provision of source code may be difficult to review, repair, or extend. In addition, there may be no owners to make such repairs on behalf of organizations. If open-source software is used, the assessments address the fact that there is no warranty, the open-source software could contain back doors or malware, and there may be no support available.
Assessment objectives and methods
- CM-07(08)(a)the use of binary or machine-executable code is prohibited when it originates from sources with limited or no warranty or without the provision of source code;
- CM-07(08)(b)
- CM-07(08)(b)[01]exceptions to the prohibition of binary or machine-executable code from sources with limited or no warranty or without the provision of source code are allowed only for compelling mission or operational requirements;
- CM-07(08)(b)[02]exceptions to the prohibition of binary or machine-executable code from sources with limited or no warranty or without the provision of source code are allowed only with the approval of the authorizing official.
Examine
- Configuration management policy
- procedures addressing least functionality in the system
- configuration management plan
- system security plan
- system design documentation
- system configuration settings and associated documentation
- list or record of binary or machine-executable code
- system component inventory
- common secure configuration checklists
- system audit records
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with responsibilities for determining mission and operational requirements
- authorizing official for the system
- organizational personnel with information security responsibilities
- organizational personnel with software management responsibilities
- system/network administrators
Test
- Organizational process for approving execution of binary or machine-executable code
- mechanisms supporting and/or implementing the prohibition of binary or machine-executable code
Related controls
CM-7(9) — Prohibiting The Use of Unauthorized Hardware
- (a)Identify [Organization-defined: hardware components];
- (b)Prohibit the use or connection of unauthorized hardware components;
- (c)Review and update the list of authorized hardware components [Organization-defined: frequency].
Official discussion
Hardware components provide the foundation for organizational systems and the platform for the execution of authorized software programs. Managing the inventory of hardware components and controlling which hardware components are permitted to be installed or connected to organizational systems is essential in order to provide adequate security.
Organization-defined parameters (2)
Assessment objectives and methods
- CM-07(09)(a)[Organization-defined: hardware components] are identified;
- CM-07(09)(b)the use or connection of unauthorized hardware components is prohibited;
- CM-07(09)(c)the list of authorized hardware components is reviewed and updated [Organization-defined: frequency].
Examine
- Configuration management policy
- network connection policy and procedures
- configuration management plan
- system security plan
- system design documentation
- system component inventory
- system audit records
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with system hardware management responsibilities
- organizational personnel with information security responsibilities
- system/network administrators
Test
- Organizational process for approving execution of binary or machine-executable code
- mechanisms supporting and/or implementing the prohibition of binary or machine-executable code
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.