What CMMC CM.L2-3.4.6 least functionality requires and why it is hard
CM.L2-3.4.6 requires you to configure each organizational system so it provides only its essential capabilities. Before an assessment, the hard part is not finding the default services, ports and utilities that ship enabled. It is agreeing on which capabilities the system actually needs, then writing that answer down so an assessor can test it. Because 3.4.6 is a 5-point requirement, it cannot go on a POA&M. If an assessor scores it NOT MET, it is subtracted from the 110-point maximum, and you need it MET to reach Conditional or Final Level 2 status.
The requirement breaks into two assessment objectives in NIST SP 800-171A: defining the essential capabilities of each system, and configuring the system to provide only those. The sibling requirement CM.L2-3.4.7 covers the other side of the same problem, restricting, disabling or blocking the nonessential programs, functions, ports, protocols and services. In practice, 3.4.6 asks you to decide what belongs on the system, and 3.4.7 asks you to prove that everything else is switched off. An assessor will look for the first decision in your configuration management plan and security configuration checklists before testing the second.
Most teams stall at the definition step. Many organizations have no written list of essential capabilities for each system type, so each administrator makes a different call about which service or utility to keep. Start by asking the system owner to list the business functions the system must perform, then map each function to the services, ports and protocols it needs. Confirm the result with your assessor's expectations and your own environment before you treat it as final, because the mapping is where most of the evidence gap appears.
Which systems, teams and third parties does least functionality cover?
Least functionality applies to every system inside the CMMC assessment boundary, not only the obvious servers and laptops. The decisions below determine which configurations must be defined, hardened and evidenced, and who in the organization or at a vendor owns each one.
CUI-processing endpoints
Workstations and laptops that open, create or store CUI are the most common population in scope. Each device type needs its own essential-capability list, because an engineering workstation and a finance laptop rarely need the same applications, services or ports. Check that the baseline covers the image used for new hires and rebuilt devices, and that removable media, remote desktop and default browser plug-ins are either justified or disabled.
Servers and their roles
Each server role, such as file, database, authentication or print, should have its own list of essential services, ports and protocols. Default server installs often enable features the role never uses. Confirm that the configuration management plan names the owner for each role and that the security configuration checklist for that role is the document an assessor will test against.
Network devices and boundary appliances
Firewalls, routers, switches and VPN gateways in the boundary often ship with management interfaces, SNMP, legacy protocols and vendor services enabled. Least functionality here means restricting management access to approved networks and disabling unused ports and protocols. Confirm whether each device's configuration export is kept as evidence and who reviews changes to it.
Cloud workloads and managed services
Virtual machines, containers and managed database or storage services inside the boundary each carry default features that the provider or image enables. Cloud consoles can also expose services that are not part of the defined baseline. Check that infrastructure-as-code templates or images encode the approved service list, and that drift from that list is detected rather than discovered during an assessment.
OT and test equipment
Specialized assets such as manufacturing controllers, instruments and test rigs often run vendor firmware that cannot take the usual agents or hardening steps. Where a device is inside the boundary, the organization must still define its essential capabilities and document any function it cannot disable. Confirm with the vendor which services can be removed, and record the compensating controls for those that cannot.
Vendor-managed systems and service providers
When a managed service provider or cloud vendor operates a system that stores or processes CUI, the least functionality decision still belongs to the organization that owns the boundary. The contract or responsibility matrix should state which party configures, reviews and evidences each restriction. Ask providers for their hardening baselines and for the evidence they can supply to an assessor.
How a CMMC assessor tests least functionality against 3.4.6
This table compares the two NIST SP 800-171A assessment objectives for CM.L2-3.4.6, showing what an assessor checks, the evidence they request and where organizations commonly fall short. Read each row as a question the assessor will ask, then confirm your own evidence answers it in final form before the assessment begins.
| Assessment area | What the assessor tests | Evidence requested | Common findings |
|---|---|---|---|
| Objective 1: Define essential capabilities | Whether the organization has defined which functions, ports, protocols and services each system needs to operate, based on least functionality | Least functionality procedures, the configuration management plan, and system documentation listing approved capabilities per system | Essential capabilities are never written down, or the list is generic and does not differ between server, endpoint and network device roles |
| Objective 1: Essential capability approval | Whether the defined capabilities were reviewed and approved by an accountable owner and kept current with the system | Signed or recorded approvals, dated revisions, and links to the system security plan | Approval records are missing, drafts are presented as final, or the list predates significant system changes |
| Objective 2: Configure to essential capabilities | Whether the system is actually configured to provide only the defined capabilities, not merely documented that way | Security configuration checklists, hardened build records, and configuration exports from representative systems | Checklists exist but were not applied, or default services and sample utilities remain enabled on sampled systems |
| Mechanism testing: functions and services | Whether processes or mechanisms restrict or prohibit unnecessary functions and services, tested on live or representative systems | Service and feature lists from sampled systems compared against the approved capability list | Unneeded services such as legacy remote access or unused management features are running and no exception was recorded |
| Mechanism testing: ports and protocols | Whether unused ports and protocols are blocked or disabled, and whether permitted ones match the approved list | Host firewall rules, listening port scans, and protocol configuration exports for sampled systems | Ports open by default are left enabled, or firewall rules allow broad ranges with no documented business need |
| Evidence status | Whether each piece of evidence is in final form and covers the systems in scope | Final, dated documents tied to the assessed system boundary, with no pending revisions | Drafts, undated screenshots, or evidence from systems outside the boundary are rejected, so the requirement cannot be marked MET |
| Scoring consequence | Whether CM.L2-3.4.6 is MET, since it cannot be carried on a POA&M | A complete MET determination across both objectives | A single unmet objective leaves the requirement NOT MET, which affects Conditional or Final Level 2 status |
How to configure systems to provide only essential capabilities
This sequence turns the least functionality principle into a documented, agreed baseline of essential capabilities, then into a hardened configuration that an assessor can test against the requirement. Each step produces an artifact that the next one depends on.
Define essential capabilities by system type and role
The system owner, with input from the people who run each system, lists the capabilities each system type needs to perform its function: services it must run, ports and protocols it must accept or initiate, applications users need, and administrative tools. Group systems by type and role, such as domain controllers, engineering workstations, and file servers, so that one list can cover many similar assets. The output is an essential capability list per system type, signed off by the system owner and tied to the system security plan. Do not start hardening until this list is agreed, because every later step measures against it.
Inventory default applications, services, ports and protocols
Using the baseline image or a live scan of a representative system of each type, record what is installed and enabled by default. Capture installed applications, running services, listening ports, and enabled protocols, including utilities that ship with the operating system. Automated discovery tools can help build this list, but a person should reconcile the output against the essential capability list. The output is a gap inventory showing every default capability that is not on the agreed list.
Disable or remove nonessential capabilities
Remove unneeded applications and default utilities where the system permits it, disable unneeded services, and close ports and protocols that the essential list does not require. Where removal is not possible, disable the capability and document that it is disabled. Make these changes through the configuration management process so each change has a record, and apply them to the baseline image so new systems start correctly. The output is a set of change records that match the gap inventory, with each removal or disablement traceable to a line in the essential capability list.
Verify the configuration against the security checklist
Compare each configured system against the security configuration checklist for its type. Confirm that unneeded services are stopped and disabled, unneeded ports are closed, and default utilities are removed or restricted. Automated compliance scanners can check many of these settings, and their results should be reviewed by a person who understands the system. The output is a verified checklist result for each system, showing which checks passed, which failed, and why any check was not applied. Failed checks go back to step three.
Record deviations with approval
Where a system needs a capability that is not on the essential list, or a required check cannot pass, record the deviation with the business or technical reason, the affected systems, the compensating controls, and the approver. Route each deviation through the change control process so the approval is on record before the system runs in that state. Review deviations on a schedule set by the organization. The output is a deviation register with approvals attached, which an assessor will check against the configuration.
Confirm monitoring keeps the configuration in place
Set up recurring checks that detect when a system drifts from its verified configuration, such as a service re-enabled or a new listening port. Route drift alerts to the people who own the baseline, and link each alert to a change record or a deviation entry. The output is a monitoring record showing that checks run on a defined basis and that drift is investigated. Ask your assessor which monitoring evidence they expect before you finalize this step.
Which open-source tools can produce least functionality evidence
Wazuh's Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. Most shipped policies are based on CIS benchmarks, and teams can add custom policies that check files, directories, registry keys and running processes, with remediation guidance for failed checks. For least functionality, this is the tab that most directly tests whether unnecessary services, settings and programs are actually disabled against your documented baseline.
- Configuration check results: Pass and fail results per endpoint show whether settings that restrict functions are in the state your baseline requires.
- Custom policies for your essential list: Policies can check that only approved processes are running or that unneeded features are absent, which maps directly to your defined capabilities.
- Policy history: Retained scan results give a time-based record that can support drift discussions.
- Licensing: Wazuh is GPL-2.0-only. Confirm the license terms that apply to your deployment and any bundled content before you rely on it in a contract.
What it cannot prove alone: a pass on a benchmark check does not show that your essential capability list is correct, and it does not check network ports unless a policy is written for them. Confirm which policies ship with your version and which you must write yourself.
Fleet policies are yes or no questions asked of devices, written as osquery queries. The policies page shows which devices in each fleet pass or fail each policy. This gives you a per-device, query-based view of whether a device matches a least functionality rule, such as whether a prohibited service is running or a default utility is present.
- Per-device pass or fail: The policies page lists which devices meet each rule, which helps show coverage across endpoints.
- Tailored queries: You can write queries for your own essential capability list, such as confirming that listening ports or installed packages match an approved set.
- Fleet-level grouping: Policies applied per fleet let you show different expectations for different system roles.
- Licensing: Fleet is MIT licensed. Confirm which Fleet edition and features your deployment uses.
What it cannot prove alone: a policy shows a yes or no answer at the time it runs, so you need retained results and a record of who changed the policy. It also depends on the osquery tables available on each platform, so confirm coverage for every operating system in scope.
Greenbone Community Edition is built on the OpenVAS Scanner, a scan engine that runs vulnerability tests from the Greenbone Community Feed, which is updated daily, against target systems. Its tests can reveal services that are reachable over the network, which is the evidence most often needed to show that nonessential ports and services are not exposed. The scanner is controlled by gvmd over the Open Scanner Protocol.
- Open service discovery: Scan results list network services the scanner can reach, which you can compare against your documented list of essential services.
- Repeatable scan records: Saved scan reports and dates give assessors a trail of what was tested and when.
- Feed updates: The daily feed means the test set changes over time, so record the feed version used for each scan.
- License caveat: The engine is AGPL-3.0-or-later. Review the obligations that apply if you modify and offer the software to others, and confirm how the feed terms apply to your use.
What it cannot prove alone: a scan shows what is reachable from where the scanner sits, not what the host is configured to run. Scans from one network position may miss services limited to other segments, and vulnerability tests do not establish that a service is essential. Pair results with host configuration evidence.
Trivy detects known vulnerabilities (CVEs) in operating system packages and language dependencies found in filesystems, Git repositories, virtual machine images and container images. It is a vulnerability scanner, not a configuration check, so it does not show whether a capability is disabled. Its value for least functionality is narrower: it can help you identify packages and dependencies in images that your essential capability list does not need.
- Package inventory: Scan output lists OS packages and dependencies in an image or filesystem, which can be compared against your approved software list.
- Image review before release: Scanning images in a build pipeline can show unneeded packages before a system is deployed.
- Scan records: Saved reports document what was found in each artifact at the time of the scan.
- Licensing: Trivy is Apache-2.0. Confirm the terms that apply to any bundled vulnerability data in your environment.
What it cannot prove alone: Trivy does not check services, ports or runtime settings, and a clean vulnerability result says nothing about whether unneeded functions are enabled. Use it as supporting evidence for software inventory, and confirm its current coverage for your operating systems and image types.
Which evidence passes least functionality and how to keep it current
An assessor testing CM.L2-3.4.6 looks for a defined list of essential capabilities, proof that the systems were configured to match it, and records showing that the list and the systems still agree. The cards below cover each artifact, what it must show, and how to keep it accurate between assessments.
Essential capability list per system type
This is the defined set of capabilities each system type needs to do its job, such as the services, ports, protocols and applications a CUI workstation or a file server requires. It is the first assessment objective for 3.4.6, so an assessor will ask who approved it and how it was derived from the system's function. Check that each system type in the SSP has its own list, not one generic list copied across the environment. Update it when a system's function changes, and keep the approval record with the list.
Configuration management plan section
The configuration management plan should state how essential capabilities are defined, who owns the list, how exceptions are raised, and how the baseline is reviewed. SP 800-171A names the plan as potential evidence for 3.4.6, so an assessor will compare its statements against what the systems actually do. Confirm that the plan's wording matches your real process and that the version in use is the one referenced in the SSP. Record the revision date and approver on each revision.
Security configuration checklists with results
A hardening checklist that lists each disabled service, closed port and removed default utility, with a recorded result for each system, shows that the configuration was applied and not only planned. Keep the checklist version tied to the baseline it implements. Retain the completed results for each system so that an assessor can sample a machine and compare its state against the checklist. Stale results that predate a rebuild or an image change are a common reason an assessor cannot confirm the configuration.
Scan and policy reports for disabled services and ports
Automated reports show whether unneeded services, ports and protocols are actually disabled on the systems in scope. Configuration assessment tools can flag running processes or listening ports that fall outside the approved list, and policy engines can return pass or fail per device. Export and retain these reports on a regular schedule your team defines, and record how each failing finding was resolved or approved. Confirm the tool covers every system type in scope, including endpoints and servers, since gaps in coverage will show up as untested systems.
Deviation approvals
Some systems need a capability that is not on the standard list, such as a legacy protocol required by a vendor application. Each such exception needs a documented business justification, a risk decision, a named approver, and an end date or review trigger. Without these records, an assessor will treat the extra capability as an unapproved one. Keep deviations in the same register as other configuration exceptions so that each can be found during the assessment.
Change records when capabilities are re-added
Whenever a service, port or application is re-enabled, the change should go through the change process and be recorded against the essential capability list. The record should show the requester, the reason, the approval, the date and the updated list entry. This connects 3.4.6 to the change management and security impact analysis requirements, so an assessor can trace a re-added capability from request to approval to the current configuration. Reconcile change records with scan reports periodically to catch any re-enablement that bypassed the process.
What meeting 3.4.6 costs in money and effort
This table lists the main cost components of meeting CM.L2-3.4.6 Least functionality, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read the drivers column first, because fleet size, the number of distinct system types and specialized equipment usually decide where the effort goes. No prices or durations are given here, so use the quote checklist to compare written proposals.
| Cost component | One-time or recurring, and who is paid | What drives it up or down | How to keep it down |
|---|---|---|---|
| Tooling or licenses | Recurring if commercial; open-source tools carry no license fee but still need hosting and staff time | Number of endpoint, server and cloud images in scope; commercial agents priced per device | Use open-source scanners and policy engines where they fit the environment, and confirm each tool's license terms in writing |
| Engineering time to define essential capabilities | One-time at first, then recurring at each baseline review; paid to your staff or a implementation partner | Number of distinct system types, roles and mission functions that need their own capability list | Group systems into a small number of standard builds and document one capability list per build |
| Hardening and configuration work | One-time for the initial build, recurring for each new image or major update; paid to your staff or a partner | Default service and port count on each platform, OT or legacy equipment that cannot be changed easily, and existing baselines | Start from a documented security configuration checklist and reuse existing baselines rather than hardening each host by hand |
| Testing that capabilities are restricted | One-time per build, then recurring after changes; paid to your staff or a tester | Number of ports, protocols and services to verify and how many processes restrict them | Automate checks with scripted configuration tests so they run again after each change |
| Evidence upkeep | Recurring; paid to your staff, reflected in the configuration management plan and checklists | How often builds change, how many versions of the capability list exist, and whether evidence is kept in final form | Keep one version-controlled capability list per system type and tie each change record to it |
| External testing or review | Recurring if scheduled; paid to a testing firm or consultant, separate from the assessor | Scope of the review, number of systems sampled, and whether a readiness review is included | Ask for a fixed-scope review of a representative sample rather than the full estate |
| Auditor or assessor sampling | Paid to an independent assessor, recurring at each assessment; DeployOpen does not issue assessment results | Number of systems the assessor samples and the quality of the evidence provided | Prepare a sample-ready evidence package per system type so assessors can test without follow-up requests |
What your team keeps, what a partner prepares, and what the assessor decides
Your organization owns the decisions that define what a system is for. Under CM.L2-3.4.6, the first assessment objective is defining the essential capabilities of each system, and that definition is a business and security judgment that only your organization can make. Your team also owns the system security plan entries that describe those capabilities, the approval of any service or port that stays enabled for operational reasons, and the decision to accept residual risk where a required function cannot be removed.
- Essential capability decisions: Name the functions, services, protocols and ports each system needs to do its job, and record who approved each one.
- System security plan entries: Describe the retained capabilities and how the system is configured to provide only those capabilities.
- Risk acceptance: Document and approve any nonessential capability that cannot be disabled, with a stated reason and review date.
- Ownership of the baseline: Keep the configuration baseline current when systems or missions change.
- Final evidence sign-off: Confirm that evidence is in final form before it is presented as proof that the requirement is met.
Before engaging anyone, confirm that a named owner can sign off each essential capability list, because a partner cannot approve it on your behalf.
An implementation partner does the technical preparation that makes the requirement achievable. Under a fixed-scope engagement, a partner can remove default utilities, disable unneeded services, close unused ports and protocols, build hardening checklists against your approved capability list, configure scanning tools, and assemble the evidence package an assessor will examine. The partner works in your environment, but the decisions and the findings remain with your organization and the assessor.
- Configurations and checklists: Apply the approved settings and write the security configuration checklists that the assessment will review.
- Scan and monitoring setup: Configure tools such as Wazuh, Fleet or Greenbone to check for nonessential services and report drift from the baseline.
- Evidence packages: Collect configuration exports, checklist results, scan reports and change records in a form that shows what was tested and when.
- Documentation support: Draft procedure text for your team to review and adopt, without making the capability decisions.
- Remediation work: Carry out approved changes and retest them.
A partner must never issue findings, mark an objective as met, or write the assessment conclusion. Ask any partner to state in writing which tasks it performs and which remain with your team and the assessor.
The assessor tests the requirement and decides whether it is met. For Level 2 certification, that means a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, performs the assessment against the assessment objectives in NIST SP 800-171A. Self-assessments follow the same objectives but are performed and scored by your organization. In either case, the assessor examines the processes and mechanisms that restrict or prohibit functions, ports, protocols and services, and checks whether the system behaves as the documentation says.
- Independent testing: Sample systems, review configurations against the stated capability list, and check that disabled services stay disabled.
- Evidence review: Examine the configuration management plan, security configuration checklists and scan results for final-form evidence.
- Scoring decision: Determine whether CM.L2-3.4.6 is MET, which is required because the requirement cannot go on a POA&M.
- Independence rules: The assessor cannot be the partner that configured the environment or the consultant that wrote the evidence.
- Reporting: Only the assessor or certification body issues the assessment result or certificate.
Before hiring any assessor, confirm its authorization status with The Cyber AB and ask how it will separate its work from any preparation work you have bought.
Most organizations outsource the technical configuration work and keep the judgment work. The split is practical: configuration and scanning require specialist hands, while capability decisions and risk acceptance require knowledge of the mission that an outside party does not hold. Cost depends heavily on how many systems are in scope, how many default services each platform ships with, and how much custom hardening your team has already done. These are the items to request in a written scope.
- Likely outsourced: Hardening builds, checklist authoring, scan configuration, evidence collection and remediation of nonessential services.
- Likely kept in house: Essential capability lists, system security plan text, risk acceptance, approval of exceptions and final evidence sign-off.
- One-time work: Initial baseline hardening, checklist creation and first evidence collection.
- Recurring work: Drift checks, reviews after each change, periodic scan reviews and re-evidencing before reassessment.
- Quote items: Systems in scope, platforms, scan tools, evidence deliverables and who signs each document.
Confirm the boundary in the statement of work before work begins, so that no partner task is later presented as an assessor conclusion.
Where least functionality evidence usually fails
Least functionality evidence rarely fails because the hardening is absent. It fails because the essential capability list is missing, the work is not written down, or the settings drift back after the next update or image rebuild. The cards below cover the failure points an assessor is most likely to find for CM.L2-3.4.6 Least functionality.
No written essential capability list
Without a documented list of the capabilities each system needs to do its job, the organization cannot show it defined essential capabilities, which is the first of the two assessment objectives for 3.4.6. Start with the system's function, then list the services, ports, protocols and applications that function requires. Anything not on the list is a candidate for removal. Ask the assessor's question of your own list: can each entry be traced to a business or security need?
Hardening done but not documented
Engineers often remove unneeded packages and disable services during build, then record nothing. An assessor cannot test a setting that exists only in someone's memory. Record each hardening decision in the configuration management plan or a security configuration checklist, with the setting, the system it applies to and the date it was applied. Tie each entry back to the essential capability list so the two documents agree.
Default services re-enabled by updates
Vendor updates, package upgrades and golden images can quietly restore services or utilities that were disabled, and they can reopen ports the hardening removed. This is configuration drift. Check the running state after each patch cycle and each image rebuild against the documented baseline, and compare running services, listening ports and installed packages rather than trusting that the earlier change persisted. Automated compliance scans on a schedule make drift visible before an assessment does.
Evidence still in draft form
A hardening checklist that says 'in progress' or a service inventory marked 'to be confirmed' does not count as evidence. Under CMMC, a requirement is MET only when all applicable objectives are satisfied with evidence in final form, not drafts. Before the assessment, freeze each document with an approver, a version and a date, and confirm that the configuration on the system matches the approved version. Drafts left in shared folders are a common reason an otherwise sound control is marked as not met.
Nonessential ports open on OT and test equipment
Operational technology, lab instruments and test equipment often ship with open management ports, unused protocols and default accounts, and they are frequently excluded from the standard hardening process. Each device that stores, processes or transmits CUI, or connects to a system that does, falls within the scope of the requirement. Inventory these assets, scan them for open ports and protocols, and document either the restriction or the business reason each open port is required. Confirm the vendor's options for disabling services before assuming they are available.
Assuming a POA&M covers this requirement
Many organizations expect to close a gap with a Plan of Action and Milestones, since the rule allows POA&Ms for some requirements. CM.L2-3.4.6 is a 5-point requirement, and the scoring rules do not allow it on a POA&M, so it must be MET to reach Conditional or Final Level 2 status. Treat this requirement as a go or no-go item before the assessment. Confirm the point value and POA&M eligibility against the current scoring rules in 32 CFR Part 170 before planning remediation timing.
How much effort does CM.L2-3.4.6 take, and can we do it ourselves?
How much effort does CM.L2-3.4.6 least functionality take to meet?
The effort depends less on the requirement itself than on how many system types you run and how much default software and how many open services they ship with. CM.L2-3.4.6 has two assessment objectives in NIST SP 800-171A: defining the essential capabilities of each system, and configuring systems to provide only those capabilities. The first step is usually a short review per system type, then hardening and verification across the fleet. Cost drivers include the number of distinct operating systems and appliances in the boundary, the number of undocumented services, and whether settings are enforced centrally or checked by hand. Ask any partner for a fixed-scope written plan that lists the system types, the hardening work and the evidence to be produced before agreeing to a quote.
Can an in-house team meet CM.L2-3.4.6 without outside help?
Yes, an in-house team can meet CM.L2-3.4.6 if it has the skills to define essential capabilities and to harden each system type. The organization owns its controls, so internal staff must make the decisions about which services and utilities stay. Outside help is most useful for scanning, drift checks and evidence preparation, where a team lacks time or tooling. Confirm internally whether you have people who can read vendor hardening guidance, write configuration baselines and run verification scans. Be aware that the CMMC Assessment Guide Level 2 notes that systems ship with many unnecessary applications and ports enabled by default, so a quick default-settings pass rarely satisfies the requirement on its own.
What does CM.L2-3.4.6 require from our system owners and approvers?
The requirement needs named people who can decide what each system is for. System owners must state the essential capabilities their systems need to operate, and approvers must accept those decisions in writing. You also need administrative access to the systems, change windows for restarts and service removal, and a way to test that business applications still run after services are disabled. Administrators should document each exception, such as a required protocol, and the reason it stays enabled. Without these inputs, the assessor will find a configuration with no documented basis, and the requirement is not met.
Can a partner run scans and prepare evidence while the assessor stays independent?
A partner can run scans, harden systems and prepare evidence, but it cannot issue the assessment result. DeployOpen plans, implements, hardens and documents self-hosted platforms in your environment, and prepares systems, controls and evidence for compliance assessments. Only an independent assessor or certification body issues reports or certificates. For Level 2 certification, assessments are performed by C3PAOs authorized or accredited by The Cyber AB. Keep the assessor independent of the team that built the evidence, and ask any provider to show who decided each essential capability and who approved each exception.
Is a POA&M an option for CM.L2-3.4.6?
No, a plan of action and milestones is not an option for CM.L2-3.4.6. The requirement is worth 5 points under the CMMC Scoring Methodology in 32 CFR 170.24, and 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a POA&M. It must be MET to reach Conditional or Final Level 2 status. This makes the requirement a priority for planning, because a gap found late can affect a contract award. Confirm the current status of the Level 2 certification timeline with the Department of War before you rely on any date, since the DoW suspended CMMC Phase II on 13 July 2026.
How do we keep least functionality evidence current between assessments?
Keep the evidence current by tying it to change control and to routine checks. The configuration management plan, the security configuration checklists and the list of essential capabilities should be reviewed whenever a system or service is added, and any new default service should be assessed before it is enabled. Automated checks help here. Wazuh Security Configuration Assessment can check configuration against YAML policies, Fleet policies show which devices pass or fail each check as osquery queries, and Greenbone Community Edition can identify exposed services for review. Schedule these checks, retain their output, and record each exception with an approval. Confirm with your assessor which artifacts they accept in final form.
How DeployOpen scopes and prepares least functionality evidence
DeployOpen works on CM.L2-3.4.6 as a fixed-scope implementation project inside your own environment. We prepare the systems, configuration baselines and evidence an assessor will test, while your organization keeps ownership of its controls and an independent assessor makes the determination.
How we scope
- Inventory the in-scope systems and list the default applications, services, ports and protocols on each one.
- Agree with your team which capabilities are essential to each system's function, and record the justification for each.
- Confirm the written scope, deliverables and timelines before any configuration work starts, with a quote following from that scope.
How we build
- Remove unneeded default utilities and disable services, ports and protocols that the documented essential capabilities do not require.
- Apply hardening settings to a configuration baseline, using a security configuration checklist mapped to each system type.
- Test that restriction mechanisms actually block unapproved functions, ports, protocols and services, and record the results.
How we hand over
- Deliver the essential capability definition, the hardened configuration baseline and the checklists as versioned, final documents.
- Provide test records showing each restricted function, port, protocol or service and the method used to verify it.
- Walk your assessment owners through the evidence so they can explain how 3.4.6 is met to an independent assessor.
How we support
- Ongoing support is available as a retainer to review new software, updates and configuration changes against the essential capability list.
- Retainers can cover periodic re-testing of restrictions after upgrades, so the evidence stays current between assessments.
- Confirm with DeployOpen during scoping which post-handover activities are included in the retainer and how they are priced.
