What CM.L2-3.4.7 nonessential functionality requires in CMMC Level 2
CM.L2-3.4.7 asks you to decide which programs, functions, ports, protocols and services your CUI system actually needs, and then to restrict, disable or prevent everything else. The first part is a documented decision. The second part is a technical control that an assessor can test on each system in scope. A CUI environment often grows through defaults, vendor installers and old project work, so it carries print spoolers, legacy file-sharing services, unused browser plug-ins, open management ports and protocols that no one can explain. The requirement is aimed at that accumulated surface. The requirement is the most objective-heavy Level 2 item because NIST SP 800-171A splits it into 15 assessment objectives. Each of the five item types (programs, functions, ports, protocols and services) must be defined as essential, its nonessential use must be defined, and that use must be restricted, disabled or prevented as defined. A single missing ports list or an undocumented service can fail the whole requirement. Under the CMMC Scoring Methodology, CM.L2-3.4.7 is worth 5 points, and because it is worth more than 1 point it cannot go on a plan of action and milestones. It must be MET for a system to reach Conditional or Final Level 2 status.
In practice, the work starts with an inventory of running services, listening ports, enabled protocols and installed programs for each in-scope asset, compared against a written list of essential items with a reason for each. Your security configuration checklists, hardening records and change control records are the natural evidence sources. Then confirm that the restriction is enforced, not just planned. Tools such as Wazuh Security Configuration Assessment and Fleet policies can show whether a disallowed service or program is present on an endpoint, but you must confirm that each check matches your own essential list and that the results are retained as final evidence. The organization owns this decision. An implementation partner can help prepare the baseline, the essential-items justification and the scan evidence, but the assessor, not the partner, judges whether the evidence meets each objective. Before you commit to a schedule, confirm the current assessment status with the DoW CIO's About CMMC page, because the Phase II suspension affects when certification assessments apply to your contracts.
Which systems, services and ports fall under the 3.4.7 scope
CM.L2-3.4.7 applies to every system in the CUI assessment boundary, not only the servers an assessor happens to sample. The cards below cover the components that carry the requirement and the scoping decisions that most often change how much work it takes.
Endpoints in the CUI boundary
Laptops, desktops and virtual desktops that store, process or access CUI are in scope. Each one needs its installed programs, enabled services and open ports reviewed against a defined list of essential items. Check that the baseline for each device model is recorded, and that a device pulled from a different image is found and brought under the same review. Remote and personal-device access paths belong here too.
Servers and their running services
Servers hosting CUI applications, databases, authentication, logging or file shares are the most common source of unneeded services and listening ports. Assessors look for a documented decision about each service, not just a clean configuration. Confirm which roles each server performs and that nothing runs by default from the operating system install.
Network devices and open ports
Firewalls, routers, switches and load balancers that protect or transport CUI expose ports, protocols and management services that must each be justified. Management interfaces, SNMP, and legacy protocols are frequent findings. Ask who owns each device's configuration and whether its enabled services appear in the same review as the hosts behind it.
Cloud workloads and container images
Virtual machines, managed services and container images inside the CUI boundary carry the same obligation as physical hosts. Base images often ship with extra packages and open ports that the running workload never needs. Check that approved images are defined, that image contents are reviewed before deployment, and that cloud security groups match the documented port list.
Shared administrative tools and vendor-managed services
Remote management agents, shared admin consoles and vendor-managed services can add programs, ports and protocols that sit outside your own build process. Decide whether each one is part of the assessed system, document what it is needed for, and confirm in writing what the vendor disables by default and what you may change. Vendor-operated services that touch CUI must be addressed in the system security plan.
The CUI enclave boundary decision
Where the enclave boundary is drawn determines which systems the 3.4.7 review must cover. A narrow boundary reduces the number of hosts reviewed but depends on strong segmentation and clear documentation of what crosses it. Confirm the boundary in the system security plan before inventories are built, because a later change to it can add systems that were never reviewed.
How an assessor tests the 15 objectives of 3.4.7
This table maps the assessment objectives in NIST SP 800-171A for CM.L2-3.4.7 across the five item types (programs, functions, ports, protocols and services) and the three actions each one requires. Read each row as a question the assessor will ask, then check that the evidence in the third column exists in final form for your system.
| Item type | What the assessor checks | Evidence requested | Common finding |
|---|---|---|---|
| Programs | A documented definition of which programs are essential, the defined use of nonessential programs, and a control that restricts, disables or prevents them | Security configuration checklists, software allow or deny specifications, and records showing the restriction is applied on endpoints and servers | Essential program list exists only as an informal understanding, with no approved document behind it |
| Functions | A defined set of essential functions, the nonessential functions that are not permitted, and settings that disable or block them | Hardening checklists showing disabled features, configuration baselines, and audit records of the settings in use | Default functions such as unneeded remote features or scripting capabilities remain enabled on servers |
| Ports | A list of essential ports with a reason for each, the nonessential ports defined as not permitted, and firewall or host controls that block them | Documented port reviews, firewall rule sets, and scan results compared against the approved port list | Open ports found in scans have no owner, business reason or documented review |
| Protocols | Essential protocols identified and justified, nonessential protocols defined, and enforcement such as disabling legacy protocols | Configuration records for protocol settings, change control records for protocol changes, and review minutes | Legacy protocols stay enabled because no one reviewed them after the system was installed |
| Services | Essential services defined, nonessential services defined as not permitted, and services stopped or disabled on each system | Service inventory per system, documented periodic reviews, and records showing disabled services in the baseline | Services listed in the baseline differ from those running on the system, and no drift review exists |
| Review cadence | Evidence that essential and nonessential definitions are reviewed at a defined frequency and updated after changes | Dated review records, approval signatures, and change tickets that reference the review outcome | Reviews are described in the SSP but no completed review record can be produced |
| Exceptions | Any nonessential item that remains in use is approved, documented and tied to a specific system and purpose | Signed exception records, risk acceptance entries, and compensating controls described in the SSP | Exceptions exist in practice but were never written down or approved |
| Restriction evidence | Proof that the defined restriction is active, not just planned, on the systems in scope | Configuration exports, policy compliance reports, and audit records showing the control was enforced over time | Documentation describes a restriction that the system does not actually enforce |
How to implement 3.4.7 step by step
This sequence turns CM.L2-3.4.7 from a policy statement into a documented, tested set of restrictions, with each step producing evidence an assessor can check against the assessment objectives in NIST SP 800-171A.
Inventory services, ports and programs per system
Start by listing, for each system in the assessment boundary, the running services, listening ports, installed programs and enabled protocols. Pull this from the operating system, endpoint management and network scans rather than from memory, because the assessor will compare your documented list with what the systems actually run. Record the system owner and the date of the inventory. The step is done when every in-scope system has a current list that matches a fresh scan with no unexplained items.
Document the essential list with a reason for each item
For each program, function, port, protocol and service on the inventory, decide whether the organization needs it for its mission or business, and write down why. Mark each item as essential or nonessential, and for essential items name the owner who approved the need. This is where the first assessment objective is met: the organization must define what is essential. Store the approved list with the system security plan so the reasoning is traceable. Done means every inventory line has a decision and a reason.
Disable or block the nonessential items
Turn off the nonessential services, close unneeded ports, remove or disable programs and block protocols that no approved use requires. Apply the change through your configuration baseline or hardening scripts so the setting can be repeated on new builds. Keep the before and after state for each system. Done means a fresh scan shows only items on the approved list, and the change records are linked to the baseline.
Set program execution controls
Decide how the organization controls which programs may run, either by permitting only approved software or by blocking known unwanted software, and document that choice. Configure the endpoint or server control to enforce it, and keep the rule set in the configuration baseline. This step covers the program execution objective in 3.4.7 and connects to the application execution policy requirement CM.L2-3.4.8. Done means you can show the enforcement setting and a test where a nonapproved program is blocked or flagged.
Schedule periodic reviews of the essential list
Set a recurring review in which the system owner checks the current inventory against the approved essential list and records any drift, new services or retired items. Assign the review to a named role, define how often it runs in your own policy, and keep the signed or dated review record. Tools such as configuration assessment or osquery-based policy checks can show the reviewer which systems fail the expected state. Done means each review produces a dated record with findings and follow-up actions.
Route exceptions through change control
When a team needs a nonessential item turned on, or an essential item turned off, submit the request through the change process rather than making the change directly. The change record should state the business reason, the security impact analysis, the approver and the updated essential list. Update the baseline and the system security plan when the exception is approved. Done means every deviation from the essential list traces to an approved change record.
Retain the evidence an assessor will request
Collect the essential list, the inventory scans, the baseline settings, the enforcement configuration, review records and approved change records into one assessment folder per system. Confirm that each document is in final form, since drafts do not satisfy the objectives. Ask your assessor or C3PAO, before the assessment, which evidence formats they accept. Done means you can walk an assessor from any listed service to its approval, its enforced setting and its latest review.
Why the periodic review is the part most teams miss
Defining the essential list is only half of CM.L2-3.4.7, and the half that lapses is the periodic review. A team can document which programs, functions, ports, protocols and services a system needs, lock them down, and still fail the requirement a year later because nobody checked the list again. Software drift is the usual cause. A patch enables a service, a vendor update opens a port, or a developer installs a utility on a server for troubleshooting and never removes it. Each change looks small, but together they move the system away from the baseline the assessor saw.
NIST SP 800-171 Rev. 2 Appendix D maps 3.4.7 to two SP 800-53 Rev. 4 controls: CM-7(1), Periodic Review, and CM-7(2), Prevent Program Execution. The first is the one teams most often skip. Assessment objectives in SP 800-171A ask for documented reviews of programs, functions, ports, protocols and services, so the review itself must leave a record. Practical evidence includes a dated review of listening ports and enabled services on each server class, a list of approved and removed items with the reason for each decision, and change records that show how new items were approved. Confirm with your assessor which review cadence and format they expect for your environment, because the requirement does not fix an interval.
Open-source tooling can make the review repeatable. Wazuh Security Configuration Assessment checks endpoints against YAML policies and can flag running processes and configuration items that differ from the expected state, and Fleet policies can ask devices yes or no questions through osquery and show which devices pass or fail each one. Greenbone Community Edition can surface unexpected open services during scheduled scans. These tools produce data, but the organization still owns the decision to keep or remove each item. Store the review outputs with the system security plan so the assessor can trace each finding to a decision.
Evidence that passes a 3.4.7 review
An assessor testing CM.L2-3.4.7 looks for proof that the organization decided what is essential, removed or blocked the rest, and checked that this still holds. The cards below cover the artifacts that carry that proof and how to keep each one current between assessments. Only final, dated records count, so drafts should be finished before the assessment window opens.
Approved essential-item lists
For each system, keep a list of the programs, functions, ports, protocols and services the mission needs, with an owner and an approval date. This document answers the first objectives in the 15 that 3.4.7 breaks into, so it must exist before any blocking evidence makes sense. Check that every item on the list traces to a business or operational need, and that the list is signed off by someone who can accept the risk. Review it when the system's function changes, not only on a calendar.
Hardened configuration checklists
Hardening checklists show which nonessential features are disabled on each system class, such as unused services, default accounts and optional protocols. Assessors treat a configuration checklist as a potential assessment object for 3.4.7, so it should name the setting, the expected value and the system it applies to. Tie each checklist back to the approved essential-item list. Record every deviation with a reason and an approver.
Port and service inventories
A current inventory of listening ports, protocols and running services per host shows what is actually active, which is the evidence an assessor compares against your essential-item list. Generate it from the systems themselves rather than from the build document, so drift is visible. Flag any service that is listening but absent from the approved list. Keep dated exports so you can show the state at a specific point in time.
Scan and policy results
Automated scans and policy checks show whether nonessential programs and services are still disabled. A Wazuh Security Configuration Assessment run against a CIS-based policy, or a Fleet policy that asks whether a prohibited program is present, produces pass and fail results per device. Keep the policy version, the run date and the failed items with their remediation or approved exception. Confirm that each tool's policy content matches your own essential-item decisions before you rely on its pass rate.
Dated periodic review records
Assessors look for evidence that nonessential functionality is reviewed on a schedule, which maps to the periodic review control in SP 800-171 Appendix D. A dated review record lists what was checked, who checked it, what changed and what was done about it. Keep the signed record, not a spreadsheet that someone updates in place. Confirm your review interval in your own procedure, since the assessor will test whether you followed it.
Change records for exceptions
When a nonessential service or program must stay enabled for a business need, the exception should move through change control with a security impact analysis and an approval. The change record connects the exception to the approved list and to the SSP. Without it, an enabled service looks like unmanaged drift. Remove or retire exceptions when the need ends, and record that closure as well.
Open-source tools that produce 3.4.7 evidence
Wazuh's Security Configuration Assessment compares monitored endpoints against YAML policies, most of them based on CIS benchmarks, and can be extended with custom policies. The checks cover files, directories, registry keys and running processes, and each failed check comes with a remediation recommendation. This gives an assessor a dated record of whether settings that disable or remove nonessential programs and services are present on each endpoint.
- Process and service checks: Policies can test whether specific running processes exist, which supports evidence that prohibited or unneeded programs are not running.
- Registry and file checks: Settings that disable features or restrict access appear as checkable items, which can be matched to your documented essential list.
- Custom policies: Organization-specific rules can express your own essential baseline rather than relying only on the shipped benchmark policies.
- Remediation output: Failed checks include recommended fixes, which feed change records under the change control process.
- Scan history: Repeated assessment results over time show whether configurations stay compliant between reviews.
What it cannot prove alone: a passing policy shows that a check matched, not that the item was deemed nonessential. Confirm with your assessor how they will accept policy mappings to your documented essential functions.
Fleet's policies ask devices yes or no questions through osquery queries, and its policies page shows which devices in each fleet pass or fail each policy. Policies can be written to test whether a nonessential program or capability is present or absent on a device. The output is a per-device pass or fail view that can be exported as a point-in-time record.
- Yes or no questions: Each policy states one condition, such as whether a named nonessential program is installed, which keeps the evidence easy to read.
- Per-device results: The policies page shows passing and failing devices within each fleet, so gaps are visible by system.
- Fleet grouping: Devices can be grouped by fleet so that different essential lists apply to servers, workstations or specialized assets.
- Failure tracking: Failing devices can be followed to remediation, supporting the record that nonessential items were removed or disabled.
- Query scope: Coverage depends on which osquery tables and devices are enrolled, so check that every in-scope asset reports.
What it cannot prove alone: a policy only tests the condition you wrote. It does not decide which functions are essential or detect functionality you did not think to ask about. Confirm the policy list matches your documented definition of nonessential items.
Greenbone Community Edition runs the OpenVAS Scanner, which executes vulnerability tests from the daily updated Greenbone Community Feed against target systems. The scanner is controlled by gvmd over the Open Scanner Protocol. Scan results show which services respond on target systems, which is the external view of ports and services that the organization has left reachable.
- Reachable services: Scans report services exposed on target hosts, which you can compare against the ports and protocols your essential list permits.
- Scheduled scans: Recurring scans produce dated results, supporting evidence that exposure is reviewed over time.
- Daily feed updates: The community feed is updated daily, so test coverage tracks recent detections.
- Target definitions: Scans run only against the targets you define, so the target list should match the system boundary in your SSP.
- Result review: Findings show where unexpected services respond, which can drive removal or a documented deviation.
What it cannot prove alone: a scan sees what responds from where the scanner sits. It does not show which software is installed locally or whether a disabled service is still needed by the business. Confirm scan credentials and network placement with your assessor, and confirm the license terms for your deployment.
Trivy detects known vulnerabilities (CVEs) in OS packages and language dependencies found in filesystems, Git repositories and virtual machine images, as well as in container images. It is a vulnerability scanner, so its evidence concerns components that are present and carry known flaws. Used with a software inventory, it helps show which nonessential packages exist in a system image.
- Package inventory: Trivy identifies OS packages and language dependencies, which can reveal installed components that are not on your essential list.
- Image coverage: It scans container images, filesystems, Git repositories and VM images, so golden images can be checked before deployment.
- Vulnerability context: Each detected CVE shows the affected component, which helps prioritize removing packages that are both nonessential and vulnerable.
- Pipeline checks: Scans can run in build pipelines so that images with unwanted packages are caught before they reach production.
- Repeatable output: Scan reports can be saved with image versions, supporting evidence for a specific configuration at a specific time.
What it cannot prove alone: Trivy does not show whether a package is running, reachable or enabled, and it does not flag nonessential packages that have no known vulnerability. Pair it with the configuration and endpoint tools above, and confirm with your assessor how image scans will be accepted as evidence.
What meeting CM.L2-3.4.7 costs in money and effort
This table breaks down the cost components of meeting CM.L2-3.4.7 by who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to compare written quotes and to see which parts you can keep in-house. No prices or durations are stated because none are supplied for this requirement.
| Cost component | One-time or recurring | Who is paid or who bears it | What drives the cost |
|---|---|---|---|
| Defining essential programs, functions, ports, protocols and services | One-time, then reviewed periodically | Internal engineers or an implementation partner preparing the definitions | Number of system types, number of distinct roles and the detail the organization records for each essential item |
| Hardening checklists and restriction settings | One-time build, then recurring updates | Internal platform team or implementation partner; open-source tooling such as Wazuh is licensed under GPL-2.0-only | Count of endpoints and servers, number of operating system and application baselines, and how many services must be disabled |
| Detection of drift and nonessential items | Recurring | Internal operations; Fleet (MIT) and Wazuh (GPL-2.0-only) are open source, so cost is labor and infrastructure | Number of monitored devices, query frequency and how many policies must be maintained |
| Vulnerability and exposed port scanning | Recurring | Internal security staff; Greenbone Community Edition (AGPL-3.0-or-later) and Trivy (Apache-2.0) are open source | Scan scope, scan frequency and volume of findings needing triage |
| Documented periodic reviews and evidence upkeep | Recurring | Internal compliance and system owners | Number of reviews per year set by your own policy, number of systems in the System Security Plan and the effort to keep records in final form |
| External testing or independent review | Optional, recurring or one-time | Specialist firm chosen under a written scope | Scope of systems tested, depth of configuration review and whether results feed a formal assessment |
| Assessor sampling, if certification applies | One-time per assessment cycle | Certified third-party assessor (C3PAO) chosen by you | Number of systems in scope, number of evidence artifacts requested and the status of the Phase II timeline in effect when you assess |
Who owns 3.4.7, who partners, and where the assessor stops
Your organization owns the requirement. CM.L2-3.4.7 asks you to restrict, disable or prevent nonessential programs, functions, ports, protocols and services, and NIST SP 800-171A expects you to define what is essential before you can decide what is nonessential. Those definitions, the decisions behind them and the people who approve them belong to you. A partner can draft material, but an assessor will look for evidence that your staff reviewed and accepted it.
- Essential list: Define the programs, services, ports and protocols each system needs for its CUI function, and record the business reason for each.
- Approval authority: Name who signs off on exceptions and who can add an item to the essential list, usually through the change control process tied to CM.L2-3.4.3.
- Periodic review: Schedule and perform the review of nonessential items, and keep the records of what was reviewed and what changed.
- System security plan: Make sure the SSP describes how restriction is implemented and matches the live configuration.
- Operating decisions: Decide whether execution control follows an allow or deny approach, a choice connected to CM.L2-3.4.8.
Before engaging anyone, confirm internally who will answer for each essential item during an assessment, because the assessor will ask those people directly.
An implementation partner can prepare the systems and evidence that show 3.4.7 is met. In practice this means building the hardening work, collecting configuration output, and packaging records so your staff can explain them. DeployOpen is one example of this kind of partner: it works inside your own infrastructure on self-hosted open-source platforms, and it does not decide what is essential for your mission or issue any assessment result.
- Configuration work: Disable or remove unneeded services, ports and packages on endpoints and servers, following the essential list your team approved.
- Scanning and policy checks: Run configuration checks such as Wazuh Security Configuration Assessment or Fleet policies, and preserve the output in final form.
- Evidence packaging: Assemble checklists, change records and audit records that map to the 15 objectives in NIST SP 800-171A.
- Remediation support: Help close gaps found by scans, with each fix tracked through change control.
- Documentation: Draft procedures for your staff to review, approve and maintain.
Ask any partner to state in writing which items you own and which they perform, and whether their scope is fixed before work begins.
Only an independent assessor issues results. For Level 2 certification assessments, that is a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. For Level 3, it is DCMA DIBCAC. The assessor tests whether 3.4.7 is met against the assessment objectives, and a requirement is MET only when all applicable objectives are satisfied with evidence in final form.
- What the assessor tests: Whether the essential definitions exist, whether nonessential items are restricted as defined, and whether reviews happened as documented.
- Where the line sits: The assessor cannot design your essential list, configure your systems for you, or write the evidence it then judges.
- Independence: A consultant who performs the assessment on the same environment it hardened creates a conflict, so keep the roles separate.
- Current status of Phase II: Phase II certification requirements were suspended on 13 July 2026, so confirm with the Department of War which assessment applies to your contract before you schedule one.
- Findings: Expect findings in writing, and plan your response through your own staff.
Confirm with your contracting officer and an authorized assessor body which assessment type your contract requires before you commit budget.
Most organizations buy outside help for the labor-heavy parts of 3.4.7 and keep the decisions in-house. Outsourcing is usually acceptable for building and scanning, but the essential list, approvals and attestations must remain with accountable staff. The cost of outside help depends on how many systems, services and ports are in scope and how much of your existing documentation is usable.
- Likely outsourced: Initial hardening, scan configuration, evidence collection, and drafting of checklists and procedures.
- Usually kept in-house: Approving the essential list, signing exceptions, owning the SSP and answering assessor questions.
- One-time work: Initial baseline hardening and the first complete review of nonessential items.
- Recurring work: Periodic review, scan runs, drift checks and evidence refresh after each change.
- Quote questions: Ask which systems and services are covered, how evidence is delivered, and whether recurring checks are included.
Before signing, compare each proposed task against the list of items your staff must own, and remove any task that would hand decision-making to the partner.
Where 3.4.7 gaps usually appear and how to close them
Most failed CM.L2-3.4.7 objectives trace back to a few recurring gaps: no per-system list of essential functions, defaults left on, ports nobody documented, reviews that never happen, unmanaged program execution, and exceptions without records. Each card names one gap, the check that exposes it and the action that closes it before an assessor arrives.
No per-system essential list
Many organizations have a generic hardening standard but no written list of which programs, functions, ports, protocols and services each system actually needs. Assessors look for the essential definition first, because every other objective depends on it. Close it by writing one list per system type, covering the workloads, business purpose and owner for each item, and signing it into the system security plan. Check that a server in the sample can be traced to its own entry, not a shared template.
Defaults left enabled
Default installs often bring extra services, sample applications, guest accounts, printing, remote management or unused protocols. These remain active because nobody decided against them, which makes the configuration hard to justify under 3.4.7. Run a comparison of running services and listening processes against the essential list, then disable or remove each unapproved item. Keep the before and after output as evidence that the default was reviewed rather than ignored.
Undocumented open ports
Firewall rules that were opened for a past project often stay in place after the project ends, and no record connects each port to a business reason. An assessor who finds a listening port with no owner will mark the objective as not met. Export the current listening sockets and firewall rules, match every port and protocol to a documented purpose, and close the ones with no owner. Repeat the match after each change window so the record does not drift.
Reviews that never happen
The assessment objectives expect a documented review of programs, functions, ports, protocols and services, and an organization that has written the review schedule but never performed it fails on evidence. Reviews should produce a dated record with the reviewer, the items checked and the decisions made. Set a recurring review on the calendar, assign an accountable owner, and keep each signed output in the configuration management repository. Ask who will sign the review and where the record will be stored before the assessment.
Program execution left uncontrolled
Systems that allow any binary to run leave nonessential programs free to execute even when they are documented as unnecessary. The CMMC Assessment Guide leaves the choice of whitelisting or blacklisting to the organization, but either way, execution must be restricted in a way that can be shown. Decide on the approach, then test whether an unlisted program can start on a sample endpoint. Keep the policy, the test result and the list of blocked or allowed items together as evidence. Coordinate this card with the 3.4.8 execution policy so the two match.
Exceptions with no change record
Teams often enable a service temporarily for troubleshooting, a vendor request or an urgent deployment, then forget to disable it and never log the decision. Without a change record, the configuration no longer matches the baseline and the deviation has no approval trail. Require every exception to carry a change ticket, an approver, an expiry date and a link to the security impact analysis. Compare current settings to the baseline each cycle and treat any unexplained difference as a finding to resolve.
How much effort does CM.L2-3.4.7 take, and can we do it in-house?
Can we meet CM.L2-3.4.7 in-house without outside help?
Yes, many organizations can, provided they have staff who understand their systems and can produce evidence in final form. The requirement is about defining what is essential, documenting the review of programs, functions, ports, protocols and services, and restricting what is not needed. Your own administrators and security staff own that work. Outside help is most useful where internal people lack time, hands-on configuration skill, or experience translating technical settings into the evidence an assessor will accept. The organization owns the control and its outcome in every case.
What drives the effort needed for CM.L2-3.4.7?
Effort scales with the number of systems, the variety of operating systems and applications, and how much of the environment is undocumented. The NIST SP 800-171A breakdown has 15 assessment objectives across programs, functions, ports, protocols and services, so each category needs its own definition of essential use and its own restriction. Costs rise when baselines are missing, when many endpoints are unmanaged, or when legacy or specialized systems need exceptions. Costs fall when configuration management and inventory already exist. Ask any provider to break the quote down by system group and by objective.
What skills and staff does CM.L2-3.4.7 require?
You need people who can read system configurations, list running services and listening ports, and explain why each one is needed for a business function. Usually this means system administrators, a security engineer who can write or review policy checks, and a compliance lead who keeps the documented reviews and the system security plan consistent. Business owners must confirm which functions are essential. Plan for the work to span both the initial review and recurring reviews, since assessors look for evidence that the review happens and that its results were acted on.
Why must CM.L2-3.4.7 be fully MET rather than placed on a POA&M?
CM.L2-3.4.7 is a 5-point requirement under the CMMC Scoring Methodology, and under 32 CFR 170.21(a)(2) a requirement worth more than 1 point cannot go on a plan of action and milestones. If it is scored NOT MET, its value is subtracted from the maximum score of 110, and it must be MET to reach Conditional or Final Level 2 status. This makes the requirement a gating item, so the work should be finished and evidenced before any assessment or affirmation. Each assessment objective must be satisfied with evidence in final form, not drafts.
How long does CM.L2-3.4.7 take to implement?
Duration depends on the size of the estate, the state of existing baselines, and how many exceptions need formal approval. Organizations with mature inventories and hardening standards usually move faster than those starting from undocumented systems. Ask your provider or internal team for a phased plan that lists the discovery of services and ports, the definition of essential use, the restriction work, the evidence collection and a repeatable review cycle. Treat any single fixed duration offered without a scope as a question to challenge.
How does the Phase II suspension affect CM.L2-3.4.7 timing?
On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. A 60-day review by the CMMC Reform Task Force followed. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. NIST SP 800-171 Rev. 2 is still the requirement set the CMMC rule incorporates, and the Department said it will enforce Rev. 2 in the interim. Because the requirement stays in force, the work is not optional. Confirm your current obligations with your contracting officer and the latest DoW CIO guidance, since the schedule may change after the review.
When should we bring in a partner for CM.L2-3.4.7?
Bring in a partner when internal staff cannot cover the discovery, hardening and evidence work within your timeline, or when you need someone to build repeatable checks and documentation. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and it prepares systems and evidence for compliance assessments under a written, fixed scope. It does not issue assessment reports or certifications. Only an independent assessor or certification body does that. Ask any partner to confirm in writing what it delivers and what remains your responsibility.
How DeployOpen scopes and prepares evidence for 3.4.7
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your environment, and prepares the essential-functionality lists and evidence that a CM.L2-3.4.7 assessment will examine. The work runs in your cloud accounts, data centers or air-gapped networks, under your ownership. Most engagements are fixed-scope, so the systems in scope, the deliverables and the timeline are written down before work starts, and the quote follows from that written scope. DeployOpen does not publish a price list.
In practice, the first deliverable is usually a definition of what is essential on each system class: which programs, functions, ports, protocols and services each role needs, and which must be restricted, disabled or blocked. DeployOpen can draft that list from your system security plan and from endpoint and server inventories, then test it against the running configuration with tools such as Fleet policies, Wazuh configuration assessment and Greenbone scans, and record the results as the documented reviews an assessor will ask for. Your organization approves the list and owns the decisions it encodes.
DeployOpen does not issue assessment reports, attestations or certifications. Level 2 certification assessments are performed by authorized or accredited C3PAOs, and the requirement is only MET when its objectives are satisfied with evidence in final form. Confirm with your assessor which artifacts they accept, and confirm the current status of CMMC phases and assessment requirements with the DoW CIO, since those are changing. Security testing, where useful, is scoped separately so that the people who prepare the evidence are not the people who certify it.
