What AC.L2-3.1.20 external connections requires and why it cannot be deferred
If you are the compliance lead, the first thing an assessor will ask for under AC.L2-3.1.20 is a complete list of every external system your people and processes connect to, and proof that you control those connections. The requirement, derived from NIST SP 800-171 Rev. 2 requirement 3.1.20, asks you to identify the connections to external systems, verify them, and control or limit both the connections and the use of those systems. NIST SP 800-171A breaks this into six assessment objectives, so a single sentence in your System Security Plan will not satisfy it. Assessors will look for the terms and conditions that govern external systems, the list of applications reachable from outside your boundary, system connection or processing agreements, and the account management records behind them. Confirm the current assessment objectives against the NIST publication before you build your evidence set.
The requirement fails most often because organizations define the boundary too narrowly. The CMMC Assessment Guide treats external systems broadly: the public internet, a company network outside the CMMC Assessment Scope such as an isolated lab, networks you do not own, and personally owned laptops, tablets and phones. Engineers who test on a home machine, contractors who log in from a vendor network, or a lab that shares a switch with a CUI enclave can each create an unassessed path into or out of the environment. Start by reconciling identity provider logs, VPN and remote access records, mobile device enrollment data and network flow data against your documented connections. Any connection you cannot explain is a finding waiting to happen.
AC.L2-3.1.20 is one of six Level 2 requirements that may never be placed on a Plan of Action and Milestones (POA&M), under 32 CFR 170.21. An assessor who finds it not met cannot let you reach Conditional or Final Level 2 status while the gap stays open, so the control must be in place and evidenced before the assessment. Build the external connection inventory and the controls that limit it early, because retrofitting them during an assessment window leaves little room for error. Confirm with your Certified Third-Party Assessment Organization (C3PAO) and the current program schedule how the rules apply to your contracts, since the Department of War has changed the timing of Phase II and the status of certification requirements.
Which external systems fall inside the scope of AC.L2-3.1.20
AC.L2-3.1.20 applies to every system outside your CMMC assessment scope that touches your environment or CUI. The CMMC Assessment Guide names several categories, and each one creates different connection and use decisions to document and test.
The public internet
The public internet is the most common external system and the one assessors expect you to address first. Any connection from an in-scope system to websites, cloud services or remote users crosses it. Check that outbound access is limited to defined destinations, that inbound paths land on managed gateways, and that the boundary is documented in your system security plan. Illustrative: a developer browsing public sites from a CUI workstation is a use of an external system that needs a rule behind it.
Company networks outside scope
An isolated lab, a test network or a branch LAN owned by your company can still be an external system if it sits outside the CMMC Assessment Scope. Ask whether any data, credentials or remote sessions move between it and the in-scope environment. Shared switches, shared Active Directory trusts and copied file shares are common ways this happens without anyone deciding to create the connection. Document each path, or remove it.
Networks you do not own
Customer sites, teaming partners' offices, hotel and conference networks, and co-working spaces are external systems you do not control. Staff who travel or work on site bring these networks into contact with CUI. Confirm which networks your people may use with CUI, whether VPN is mandatory on them, and how you record exceptions. Your controls cannot inspect a network you do not own, so the control is the rule that limits what the connecting device may do.
Personally owned laptops, tablets and phones
Personally owned devices are external systems when they connect to your network, access email, or hold CUI in any form. Decide in writing whether personal devices may touch CUI at all, and if they may, which applications and sessions are allowed. Check that enrollment, remote access and mobile device connection controls apply to them. Ask your provider what is logged for personal devices, since that determines what assessors can review.
Partner managed networks
A managed service provider or outsourced IT firm that administers your systems is itself an external system if its network can reach your environment. Scoping decisions here change the work most. If the provider's tools, admin accounts or monitoring stations can see CUI, they usually fall inside your assessment scope and must meet the same requirements. If they only manage a separate network with a documented, restricted connection, the connection and its use become the control evidence.
Subcontractor systems that touch CUI
A subcontractor that receives, processes or stores CUI, or that can reach a system holding it, changes your assessment boundary. Confirm which of its systems touch CUI, what agreements define the connection, and whether its own assessment status is in place before exchanging data. Where a subcontractor only handles non-CUI work with a separate account and no path to CUI systems, document that separation. Ask your assessor early how it will treat the boundary.
How an assessor tests AC.L2-3.1.20 against NIST SP 800-171A
This table maps the six NIST SP 800-171A assessment objectives for AC.L2-3.1.20 to the test approach, the evidence an assessor requests and the findings that most often stop a requirement from being MET. Read it as a checklist of what must exist in final form before an assessment begins, because a single missing objective leaves the whole requirement unmet.
| Objective or object | What the assessor tests | Evidence requested | Common findings |
|---|---|---|---|
| Identify connections to external systems | Whether the organization has a current list of the external systems its CUI environment connects to, including personally owned devices and networks outside the assessment scope | Inventory of external connections, network diagrams showing boundary crossings, and the list of applications accessible from external systems | Connections to vendor portals, home networks or isolated labs that never appear in the inventory |
| Verify connections to external systems | Whether the identified connections are checked against authorization, such as a signed connection or processing agreement, before use | Connection or processing agreements, terms and conditions for external systems, and records showing who approved each connection | Agreements that are unsigned, expired, or cover a different system than the one connected |
| Control or limit connections to external systems | Whether connections are restricted to the approved list and enforced by technical or procedural means | Firewall or access rule exports, configuration evidence and the procedure for adding or removing a connection | Rules that are broader than the approved list, or a policy with no matching configuration |
| Identify use of external systems | Whether the organization knows which external systems are used to store, process or transmit CUI, and for what purpose | Account management documents, application lists and records of which staff use which external services | Staff using personal cloud storage or messaging for CUI without any record of that use |
| Verify use of external systems | Whether use is checked against the terms and conditions the organization set for external systems | Terms and conditions for external systems, account reviews and records of periodic checks against those terms | Terms that exist as a template but are never applied to actual accounts or users |
| Control or limit use of external systems | Whether use is restricted to what the organization authorized, such as no CUI upload to unapproved services | Usage restriction rules, configuration evidence from the tools that enforce them, and records of exceptions | Enforcement that exists only on paper, with no logs or configuration that show the restriction working |
| Evidence status at assessment | Whether each artifact is final, approved and dated, rather than a draft | Approved versions with dates and owners, signed by the accountable person | Draft agreements, unapproved diagrams or evidence dated after the assessment started |
How to implement external connection control step by step
This sequence moves from knowing every external connection and personal device in use to proving, through logs and reviews, that the organization limits them as its own terms require. Each step produces a record an assessor can examine for AC.L2-3.1.20.
Build the inventory of external systems and devices
Start by listing every external system that staff or processes can reach from inside or near the CUI environment. Include the public internet, company networks outside the assessment scope such as an isolated lab, networks the company does not own, and personally owned laptops, tablets and phones that touch company resources. Assign an owner to each entry and record which CUI, if any, could flow across it. The step is complete when the inventory is approved by the system owner and reconciled against network and identity records, so nothing is known only from memory.
Define terms and conditions for external use
Write the rules that govern use of each external system category. Specify who may use external systems, which applications are accessible from them, what data may be handled there, and which devices qualify. Address personally owned devices directly, including whether they may be used at all and under what configuration. Management approves the document, and the output is a signed terms and conditions record that users can be shown and asked to acknowledge.
Document connection and processing agreements
For each external system that a company-controlled or partner environment relies on, document the connection or processing agreement. The agreement should state who operates the external system, what data crosses the connection, how accounts are managed, and who may act for the company. Legal or contracts staff should review these with the system owner. The output is a current agreement file for every external connection in the inventory, with gaps listed as open items to close before the next step.
Enforce boundary and use rules technically
Translate the approved rules into controls that act without relying on user judgment. Configure the boundary firewall to permit only the documented external destinations and ports, using address aliases where they help keep rules readable. Restrict access to CUI repositories and collaboration platforms by user group, IP address and device criteria, so that files cannot be downloaded or synced from disallowed locations. Where web traffic carries CUI-bearing applications, add an application layer control such as a web application firewall. Your evidence is the exported rule set and configuration files, tested by attempting access from an unapproved external location and recording the denial.
Verify connections through logs and access reviews
Confirm that the controls work as written by reviewing logs from the firewall, the collaboration platform and identity systems. Check that connection attempts from external systems are recorded, that denied attempts appear, and that personally owned devices are visible when they authenticate. Sample activity against the inventory to find connections that appear in logs but not in the register, and treat each one as a finding. The output is a dated verification record listing the sampled connections, the results, and the corrective actions taken.
Close gaps and document final evidence
Resolve each finding by either removing the connection, updating the rules and agreements, or formally accepting the residual risk under management authority. Keep AC.L2-3.1.20 in the MET state only when all applicable assessment objectives are satisfied with evidence in final form, not drafts. Because this requirement cannot be placed on a POA&M, unresolved items must be fixed before the assessment rather than deferred. Package the inventory, terms, agreements, configuration exports, test records and verification logs in one evidence folder mapped to the objectives in NIST SP 800-171A.
Set a recurring review of external connections
Schedule a recurring review that repeats the inventory, agreement check, rule review and log sampling, and assign an owner to run it. Trigger an earlier review whenever a new external system is adopted, a partner connection changes, a new device policy is introduced, or a user population changes. Record each review with its date, reviewer, changes made and sign-off. The output is a continuing review log that shows the connection list stayed accurate between assessments, which is the evidence an assessor will ask for first.
How firewall rules and access controls enforce external connections
Enforcement for AC.L2-3.1.20 starts at the boundary, where a stateful packet filter decides which sources and destinations may cross between the assessed environment and any external system. A well-scoped rule set names the permitted source groups, destination hosts, ports and protocols, denies everything else by default, and logs each rule match so the assessor can see that the connection was actually controlled. Open-source options such as OPNsense publish rule documentation covering these elements, including aliases for grouping addresses and per-rule logging, but the capabilities of any specific firewall, cloud security group or managed gateway should be confirmed in your own environment before you cite them as evidence. Ask your team to export the live rule set and a sample of match logs, and check that each rule traces back to an approved external system in your connection inventory.
Packet filtering alone does not control what moves through a connection that is allowed. A hosted service reachable from outside the boundary can still accept uploads, sync data to personal devices or expose content that should stay inside the CUI scope. Application-level controls close that gap. For example, Nextcloud's File Access Control app can deny upload, download, sync or modification of files when rules match on user group, IP address, file type or user agent. Confirm the rule types and enforcement behavior of each application you run, test them with a non-CUI sample file, and record the results. Where the application cannot restrict a function, you need a compensating control or a documented decision that the function is out of scope.
Treat these enforcement points as evidence producers, not only as defenses. Map each rule or application policy to the external system it governs, the authorized user population and the CUI category involved, then store the configuration, change history and periodic test results together. A rule that exists but cannot be shown to match traffic, or a file policy nobody has tested, will not satisfy the assessment objectives. Review the rules when external systems are added or retired, because stale allowances are a common finding. Your implementation partner can prepare this configuration and evidence package, while the assessor determines whether it meets the requirement.
Evidence that passes an AC.L2-3.1.20 assessment
An assessor testing AC.L2-3.1.20 looks for proof in three places: the list of external systems and the agreements that govern them, the technical controls that enforce those connections, and the records showing the arrangements are still in force. The cards below cover the artifacts that usually satisfy each objective and the habits that keep them current between assessments. Drafts do not count, so every artifact needs a final version with a clear owner and date.
External system inventory
This is the register of every external system the organization connects to or uses, including the public internet, company networks outside the assessment scope such as an isolated lab, networks the company does not own, and personally owned devices. Assessors check that the inventory matches what the network and firewall actually show. Review it whenever a new SaaS tool, partner link or personal device program is added. Ask who approved each entry and when it was last verified.
Signed terms for external use
The terms and conditions for external systems set out what staff may do on a non-organizational system, which data may never leave the boundary, and which applications are reachable from outside. Assessors look for a final, approved version and proof that users acknowledged it. Confirm that the signed acknowledgements cover contractors and administrators, not only employees, and that the document names the CUI categories it restricts.
Connection and processing agreements
For each external system that stores, processes or transmits CUI, keep a signed connection or processing agreement that defines data handling, access rights and incident contacts. An assessor will ask which external providers hold CUI and request the agreement for each. Check that the agreement references the security requirements the provider must meet and that it has not expired or been superseded without a replacement on file.
Firewall rules with aliases and logging
Firewall rule sets are the enforcement evidence for controlling connections. Export the rule set and show the aliases that group approved external addresses, along with a default deny rule and logging enabled on rule matches. OPNsense, for example, lets administrators pass, block or reject traffic by source, destination, port and protocol and log each match for review. Assessors compare the rules against the inventory, so every approved external path should map to a named rule.
Personal device usage rules
Personally owned laptops, tablets and phones are external systems under the Level 2 assessment guide when they touch organizational resources. Keep a written rule that states which personal devices may connect, which applications they may reach and what happens when a device is lost or an employee leaves. Assessors will ask for the rule and for examples of how it was enforced, such as conditional access or blocked connections for unmanaged devices.
Access logs and review records
Logs from the firewall, remote access gateway and file platforms show whether external connections were limited to authorized use. Retain them according to your audit policy and keep dated review records showing someone examined unusual external activity. In Nextcloud, the File Access Control app can deny upload, download or sync based on IP address or user agent, and its decisions should appear in logs you can present. Confirm that the review records name the reviewer and the findings.
What meeting AC.L2-3.1.20 costs in money and effort
Tooling covers the software and hardware that enforce external connection controls: a firewall or gateway that identifies and limits traffic to external systems, a web application firewall where public-facing services exist, and content controls for file sharing platforms. Commercial products usually charge a license or subscription that recurs each year, while open-source platforms such as OPNsense (BSD-2-Clause) remove the license line but still need hardware or cloud compute, storage and support time. Coraza (Apache-2.0) and the File Access Control app for Nextcloud (AGPL-3.0-only) follow the same pattern. Confirm with each vendor which features you need, because a license tier often gates them.
- Recurring license spend: Commercial firewall, gateway or logging subscriptions renew annually and often scale with users, throughput or the number of connections.
- Open-source removal of license spend: Self-hosted open-source components remove the license line, but the compute, storage and hardware that run them remain.
- One-time hardware or setup: Appliances, virtual machines and initial configuration are typically one-time costs, with replacements and refresh cycles recurring.
- Drivers that raise cost: Number of external connection points, high availability requirements and log retention periods.
- Quote request: Ask for each license, its renewal term, which features sit in which tier and the hardware assumed.
Confirm that the tooling you select can record the connections and the external system usage that your assessor will ask to see.
Most of the cost sits in staff time. Someone must identify every external system your users reach, decide which ones are authorized, write the rules that verify and limit those connections, and test that the rules work. Personally owned devices, isolated lab networks and networks you do not own all fall within the external systems category in the CMMC Assessment Guide Level 2, so each needs a decision and a configuration. This work is one-time for the initial build and recurs whenever a new connection, partner network or device type appears.
- Discovery and inventory: Mapping every external system in use, including cloud services and partner networks, is usually the largest first-time effort.
- Rule design and configuration: Writing allow and deny rules by source, destination, port and protocol, plus aliases for address groups, takes engineering review.
- Testing: Proving that a blocked connection stays blocked requires test cases that you run and record.
- Drivers that raise cost: Many business units, legacy systems with unclear dependencies and a flat network without segmentation.
- Drivers that lower cost: A current asset inventory, an existing network boundary design and clear ownership for each external connection.
Ask your implementation partner which tasks are in the fixed scope and which are counted as ongoing support.
Assessors need evidence that the control operates over time, not only at a single point. For AC.L2-3.1.20 this typically includes the terms and conditions for external systems, the list of applications accessible from external systems, system connection or processing agreements and account management documents, as listed in NIST SP 800-171A. Keeping these current is a recurring task, and the cost rises with the number of connections and the frequency of change. Evidence must be in final form to count, so drafts and out-of-date lists do not help.
- Recurring reviews: Connection agreements, the external system list and account records need periodic review and sign-off.
- Log retention and review: Firewall or gateway logs of external connections must be kept and reviewed, which uses storage and analyst time.
- Change records: Each new external connection or rule change needs a documented approval.
- Drivers that raise cost: Frequent changes to partner integrations, many agreements to track and short review cycles.
- Quote request: Ask whether the partner prepares templates for these documents and whether evidence collection is part of the fixed scope or billed hourly.
Confirm with your assessor which evidence formats they accept before you build the process.
Outside testing and review are optional for the assessment itself, but many organizations buy them to check that external connection controls work before an assessor arrives. A security test of your boundary can reveal paths that the rule set misses, such as a personal device reaching internal systems through an unmanaged route. DeployOpen runs security testing for networks, applications and APIs, and that work is scoped and priced in writing before it starts. Testing is typically a one-time project per scope, with retests after remediation and periodic repeats as connections change.
- Scoped test engagement: Network or boundary testing is usually a fixed-scope project, with the systems, addresses and rules agreed in advance.
- Retesting: Fixes to findings require a second test to confirm closure.
- Periodic repeat testing: Connection changes or new external systems justify another test cycle.
- Drivers that raise cost: The number of external paths in scope, the depth of testing and the number of retests.
- Quote request: Ask for the test scope in writing, the method used, the deliverable format and the retest terms.
Do not treat a test report as assessment evidence. Only the independent assessor issues the result.
The assessment itself is performed by an independent assessor, and the organization pays that assessor for time, not for a result. For Level 2 certification, assessments are performed by C3PAOs, and the assessor tests AC.L2-3.1.20 against the SP 800-171A objectives, which covers identifying, verifying and controlling both connections and use. The effort depends on how well your evidence matches those objectives and whether you can demonstrate enforcement, not just a written policy. Current CMMC timing is in flux after the Department of War suspended Phase II on 13 July 2026, so confirm the assessment requirement that applies to your contracts before you budget.
- Assessor fees: Assessor effort is billed by the assessor, and the quote should state the assumed days, sites and sample size.
- Preparation time: Internal staff time to gather evidence, answer questions and walk the assessor through the rules is a real cost even though it is not an invoice.
- Drivers that raise cost: Gaps found during the assessment, unclear network boundaries and evidence that exists only as drafts.
- Drivers that lower cost: A completed self-assessment, a current boundary diagram and rules that log each match.
- Quote request: Ask your assessor or consultant to itemize assessment fees, preparation support and any re-assessment terms.
Before you sign, confirm the assessment type, the scope and any ongoing reporting obligations with the Department of War guidance and your contracting officer.
Open-source tools that produce AC.L2-3.1.20 evidence
This table compares three open-source components that can produce evidence for external connection control: OPNsense at the network boundary, Nextcloud File Access Control for file movement, and Coraza for hosted web services. Read each row as a question to answer in your own environment, because a tool only helps if it covers a connection path your assessment scope actually uses. The main takeaway is that no single tool covers every external system, so the boundary, application and license decisions must be mapped together.
| Tool | Control point and evidence it can produce | License and what to confirm |
|---|---|---|
| OPNsense | Boundary rules that pass, block or reject traffic by source, destination, port and protocol, with per-rule match logging in the live log view. Rule exports and alias lists show which external destinations are permitted. | BSD-2-Clause. Confirm that your rule set covers every route from CUI systems to external networks, including lab and partner networks outside the assessment scope. |
| Nextcloud File Access Control app | Rules that deny upload, modification, deletion, download and sync based on user group, IP address, collaborative tags, MIME type, file name, request time or user agent. Rule configuration plus denial records show limits on file movement to external devices or networks. | AGPL-3.0-only. Confirm that rules restrict personally owned devices and external clients well enough to meet your access policy, and review your AGPL obligations with counsel before modifying the code. |
| Coraza web application firewall | Inspection of requests to hosted web services using ModSecurity SecLang rulesets and the OWASP Core Rule Set, with audit logs of blocked requests. Shows what external traffic reaches a publicly reachable application that holds or serves CUI. | Apache-2.0. Confirm integration with your reverse proxy (Caddy, HAProxy, Traefik or Nginx) and that it protects only the web services you have listed as external-facing. |
Who owns the control, who prepares evidence and who assesses it
Your organization owns AC.L2-3.1.20 and remains accountable for every external connection to and use of external systems, whether or not you hire help. Leadership and the security function decide which external systems are permitted, which personally owned devices may touch CUI, and which company networks sit outside the assessment scope. Those decisions must be written down and approved before anyone configures a firewall rule.
- Policy and approval: Set the rules for external systems, including the public internet, networks you do not own, isolated labs and personally owned laptops, tablets and phones.
- Agreements: Sign the terms and conditions, system connection or processing agreements and account management documents that govern each external system.
- Application list: Decide which applications may be accessed from external systems and who may access them.
- Operation: Review connection logs, grant or revoke approvals and handle exceptions as they arise.
- Attestation: Your Affirming Official and internal owners stand behind the evidence you present.
Before you engage anyone, confirm that your approval records and signed agreements already exist in final form, because assessors will not accept drafts.
An implementation partner such as DeployOpen prepares the systems, rules, inventories and evidence that show how your organization meets the objectives of AC.L2-3.1.20. The work happens inside your own infrastructure, and the partner does not own the control, sign your agreements or decide what counts as an approved external system. Scope, deliverables and timelines are agreed in writing before work starts.
- Inventory: Help build the list of external systems, personally owned devices and outside networks that connect to or touch the environment.
- Technical enforcement: Configure boundary rules, such as firewall aliases and rule logging, and application-layer controls that limit use of external systems.
- Evidence preparation: Gather configuration exports, rule sets, log samples and approved application lists in a form your team can present.
- Documentation: Draft procedures and system documentation for your review, with your team approving the final versions.
- Gap work: Identify where objectives are not yet met and remediate them before assessment.
DeployOpen prepares systems and evidence for assessment. It does not issue reports, certificates or assessment results. Ask any partner to state this boundary in its statement of work.
Only an independent assessor can test AC.L2-3.1.20 for a Level 2 certification assessment and issue findings. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. The assessor examines the evidence against the NIST SP 800-171A assessment objectives and records whether each objective is met.
- Independence: The assessor must be separate from the team that configured your systems, so the partner that prepared evidence should not perform the assessment.
- Testing: The assessor interviews staff, examines documents such as agreements and application lists, and observes or samples the configuration and logs.
- Findings: The assessor determines whether the requirement is MET, based on evidence in final form.
- Certification: Only the assessor and the assessment process can result in a certification outcome.
- Status changes: Check current program rules before planning, because the timing of Phase II requirements has changed.
Ask potential C3PAOs how they handle conflicts of interest and what evidence they expect for personally owned devices.
Where organizations fail AC.L2-3.1.20 and how to close each gap
Most failures on AC.L2-3.1.20 come from connections nobody wrote down, not from missing technology. The cards below cover the gaps assessors find most often, and each one pairs the gap with a closure action the organization can finish before its assessment.
Personal devices used for company email
Staff often read company email on personal phones or laptops that never appeared in an inventory. Under AC.L2-3.1.20, a personally owned device is an external system, so each access path needs an identified connection and a control on what it may reach. Start by asking the mail platform for a list of devices and accounts that have synced, then decide which ones are allowed and under what conditions. Unlisted devices are the gap assessors find most often.
Isolated labs left out of the inventory
A test lab or proof-of-concept network outside the CMMC Assessment Scope can still touch CUI through shared credentials, copied files or a bridge host. The CMMC Assessment Guide treats such a network as an external system, so the organization must identify it and document how it connects. Confirm whether any data, credential or administrative path crosses from the lab into the assessed environment, and record the answer in the system security plan.
Undocumented vendor network connections
Managed service providers, software vendors and support engineers often reach internal systems through VPNs, site-to-site tunnels or jump hosts that were set up years ago and never recorded. Each of these is a connection to an external system that the organization must identify, verify and control. Build a list from firewall configuration, VPN profiles and vendor access records, then match every entry to a named business owner and a documented purpose.
Firewall rules without logging
A rule that permits or blocks traffic to an external system proves little if no one can show that it was applied or reviewed. Verifying the connection requires evidence of what passed and what was denied. In OPNsense, for example, the option to log each rule match can be enabled per rule, and the log should be retained and reviewed on a schedule the organization defines. Test one rule end to end and keep the log output as evidence.
Unsigned or outdated connection agreements
Assessors look for the terms and conditions that govern external systems, system connection or processing agreements, and the list of applications reachable from outside. An agreement that is unsigned, expired or no longer matches the actual connection fails the objective even when the technical control works. Review each agreement against the current architecture, confirm signatures and dates, and replace any that describe connections that have since changed.
Usage limits never written down
Identifying a connection is not the same as limiting what it may do. Assessors check whether the organization has defined which applications external systems may access and what those systems may do with CUI, such as whether files may be downloaded to a personal device. The gap is usually a missing list of allowed applications or an access policy that nobody enforces. Write the limits per connection type, then configure the enforcing control, such as the file access rules in Nextcloud, to match them.
Common questions about AC.L2-3.1.20 cost, effort and outsourcing
Do personally owned devices have to be covered by AC.L2-3.1.20?
Yes, if those devices connect to systems in the assessment scope or access CUI. The CMMC Assessment Guide for Level 2 treats personally owned laptops, tablets and phones as external systems, along with the public internet and company networks outside the assessment scope, such as an isolated lab or a network the company does not own. The requirement does not ask you to manage those devices in full. It asks you to identify the connections, verify them and control or limit what they can reach and do. Start by listing every path, including personal devices used for email or messaging that touch CUI, and decide for each one whether it is allowed, limited or blocked.
How much effort does the external connections inventory take, and what drives it?
The effort depends mostly on how many external paths reach your assessment scope and how well those paths are already documented. The main drivers are the number of external systems and cloud services, the number of personal or unmanaged devices in use, the number of partner or subcontractor connections, and whether network diagrams and account records are current. Assessors look for evidence such as terms and conditions for external systems, the list of applications reachable from outside, system connection or processing agreements and account management documents. Ask any consultant or partner to quote from a written scope that names the systems, sites and connection types they will review, because the inventory effort follows directly from that list.
Can a partner or consultant do the AC.L2-3.1.20 work for us?
A partner can prepare much of the work, but your organization still owns the control and the decisions behind it. An implementation partner can help map external connections, configure enforcement on firewalls and web application controls, draft connection agreements and organize evidence. Only the organization can decide which external systems are authorized and what the business accepts. For Level 2 certification, a C3PAO assesses the environment independently, and only an independent assessor issues the result. Note that the CMMC Phase II suspension announced on 13 July 2026 affects when certification is required, so confirm the current status with your contracting office before you buy an assessment.
Why can AC.L2-3.1.20 never be placed on a POA&M?
AC.L2-3.1.20 is one of six requirements that 32 CFR 170.21(a)(2)(iii) names as ineligible for a plan of action and milestones, so it must be fully MET before an organization can reach Conditional or Final Level 2 status. The reasoning follows from the risk. Uncontrolled external connections are a common route for CUI to leave the environment, so the rule does not allow the gap to be deferred. In practice, this means the connection inventory, the controls and the supporting agreements must be in final form at assessment time. Drafts do not count, so plan the documentation earlier than the technical work.
What does the work need from our staff?
The work needs input from people who know the network, the business and the contracts. Network and security engineers need to confirm firewall rules, remote access paths and any cloud or partner links. IT administrators need to provide account management records and device lists. Contract and legal staff need to review terms for external systems and connection agreements. Managers need to confirm which personal devices and external services staff actually use for CUI work. Ask your partner to name these roles in the written scope and to set a review schedule, so the people involved can answer questions quickly during the assessment preparation period.
Which open-source tools can help enforce AC.L2-3.1.20 controls?
Several open-source platforms can produce evidence for this requirement, provided they are configured and documented for your environment. OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, and it can log each rule match for review. Nextcloud (AGPL-3.0-only) includes a File Access Control app that can deny upload, download, sync and other actions based on user group, IP address, user agent and other rules. Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. Confirm each tool's fit for your architecture before you rely on it, and keep the rule exports and logs as evidence.
What is the one-time work and what recurs after the assessment?
The first pass is largely one-time work: building the inventory, defining which external systems are allowed, drafting agreements and configuring enforcement. After that, the work recurs. New cloud services, new partners, new personal devices and rule changes all require the inventory to be updated and the evidence refreshed. Assessors expect the records to reflect the current environment, so set an owner for the list and a process for approving new connections. When you request a quote, ask how the partner will hand over the inventory, rule configurations and procedures, and how it will support updates after the initial engagement.
How DeployOpen prepares external connection controls and evidence
DeployOpen works on AC.L2-3.1.20 by preparing the systems and records that show which external connections exist, how they are verified, and how their use is limited. The organization keeps ownership of its controls and decisions, and an independent assessor is the party that tests and scores them.
How we scope
- Each engagement starts with a written scope that lists every external system, public internet path, outside network and personally owned device in question.
- We map which connections sit inside and outside the CMMC assessment boundary so the 3.1.20 scope is agreed before work begins.
- Engagements are fixed-scope, so deliverables and timelines for external connection controls are agreed in writing first, with ongoing support available as a retainer.
How we build
- We configure firewall rules on OPNsense so traffic to and from external systems is passed, blocked or rejected by source, destination, port and protocol.
- We define address aliases and rule logging so each permitted external path has a documented purpose and a reviewable record of matches.
- We configure Nextcloud file access control rules where needed, restricting upload, download and sync by user group, IP address or user agent.
How we hand over
- We document the connection inventory, approved external systems, terms for external use and the configuration exports an assessor will request.
- We provide test notes showing how each of the six 3.1.20 assessment objectives can be demonstrated, so your team can confirm evidence is in final form.
- We hand over runbooks for reviewing connection logs and updating the inventory, and we confirm with your assessor which artifacts they expect.
How we support
- Ongoing support, upgrades and continuous testing of the boundary controls are available as retainers after the initial handover.
- We can re-test external connection rules after changes to network design, remote access, or personally owned device policy.
- Your organization decides when a connection is approved, and the independent assessor decides whether the requirement is met.
