SC.L2-3.13.5 Public-access system separation: evidence

What SC.L2-3.13.5 asks for and why a DMZ alone may not satisfy it

A defense contractor that runs a public website, customer portal or API alongside systems that hold CUI has to show an assessor that the public components sit in subnetworks separated from the internal network. SC.L2-3.13.5 asks for exactly that: the organization must identify its publicly accessible system components and place their subnetworks physically or logically apart from internal networks. The risk is straightforward. A compromised web server that shares a flat network with file shares, engineering repositories or authentication services gives an attacker a short path to CUI. This is a 5-point requirement that must be MET. Under the scoring rules, it cannot go on a POA&M, so an unresolved gap here blocks Conditional or Final Level 2 status.

Separation is hard in practice for reasons that are rarely about the firewall itself. Public hosts accumulate over time: a marketing landing page, a vendor-hosted form, a test API someone stood up for a demo. Many of them are absent from the system inventory, so the assessor's first question about "publicly accessible system components" cannot be answered. Cloud accounts create a similar problem when public workloads share a subscription, virtual network or security group with CUI systems. Confirm that your asset inventory tags each internet-facing component, that every tagged component sits in a documented segment, and that no public workload has a route into the internal network except through a controlled path.

A DMZ diagram alone is weak evidence. The assessor will look for the boundary protection hardware and software, the list of key internal boundaries and the enterprise security architecture documentation that NIST SP 800-171A identifies as potential evidence, and will test whether the boundary mechanisms actually block traffic from the public segment to internal hosts. Ask a practical question before the assessment: if the public web server were fully compromised, which internal addresses could it reach, and can you show that from configuration and from a test? The NIST SP 800-171A assessment guide sets out the objectives. Where no publicly accessible systems exist in your Assessment Scope, the objective may be assessed not applicable, but that determination needs documented support.

Which systems, teams and third parties fall under public-access separation

Public-access separation applies only to the components that the public can reach and that sit inside the CMMC Assessment Scope. The decisions below determine whether the requirement applies at all, where the boundary is drawn, and who must produce the evidence.

Public websites and marketing sites

A public website that is hosted by your organization, or by a third party on your behalf, is a publicly accessible system component. Confirm whether the site shares a server, database, identity store or content management account with any internal system. If it does, the site sits inside the assessment scope and needs a separate subnetwork or cloud environment. If the site is fully hosted by an outside provider with no connection back to internal systems, document that separation and retain the provider's evidence for your assessor.

Customer portals and APIs

Customer portals and external APIs usually authenticate users and exchange CUI or contract data with internal systems, which makes them the most common point where separation fails. Map every data flow from the public component to internal back-end services, including service accounts and integration credentials. Each path that crosses the boundary should pass through a controlled interface, not a direct connection to an internal database or directory.

Email gateways and inbound mail relays

An email gateway that accepts traffic from the internet is publicly reachable, even though users treat it as internal infrastructure. Determine where the gateway sits relative to the mail server that stores CUI, and whether the relay has direct routes into internal networks. Confirm that the gateway is placed in a separate subnetwork and that only the mail flows it needs are permitted between it and internal systems.

VPN concentrators and remote access endpoints

A VPN concentrator is an internet-facing component that terminates connections into internal networks, so assessors often treat it as the clearest public-access system. List it explicitly in your boundary documentation, including its management interface, and confirm that the management plane is not reachable from the public side. Remote access rules overlap with SC.L2-3.13.1 and SC.L2-3.13.7, so keep the evidence consistent across the three requirements.

Hosting providers and managed service providers

A hosting provider, cloud provider or managed service provider can operate components that are publicly reachable and that connect to your systems. Your scope depends on how responsibility is split in the contract and in the provider's own assessment evidence. Ask each provider which of its components face the internet, how they are separated from its own internal management networks, and what evidence it can supply for the boundary it controls.

Determining whether the requirement applies

An assessor may mark SC.L2-3.13.5 not applicable only when no publicly accessible systems are in the CMMC Assessment Scope. Before claiming that, inventory all internet-facing addresses, DNS records, cloud public endpoints and third-party integrations tied to your environment, and record why each one is out of scope. A single overlooked public endpoint removes the not-applicable position and makes the requirement a scored gap.

How an assessor tests public-access separation against NIST SP 800-171A

NIST SP 800-171A breaks SC.L2-3.13.5 into two assessment objectives, and an assessor must satisfy both before the requirement is MET. The first asks whether the organization has identified its publicly accessible system components, such as a public website, a customer portal, a public API gateway or a mail relay. The second asks whether the subnetworks that hold those components are separated, physically or logically, from internal networks. Because the requirement is worth 5 points and cannot go on a POA&M, a gap in either objective blocks Conditional or Final Level 2 status. Before the assessment, the organization should produce a current list of every internet-facing component and confirm that each one sits in a segment that is not the internal network.

The evidence list in SP 800-171A for this requirement is practical. Assessors look for boundary protection procedures, a list of key internal boundaries, the boundary protection hardware and software in use, enterprise security architecture documentation and audit records. A network diagram alone rarely satisfies the second objective. Assessors ask to see the rule sets on the firewall or cloud security groups, confirm that the public segment has no route to internal address ranges except through defined and logged paths, and review the logs that show those controls operating. In a self-hosted environment, a practical check is to export the firewall configuration on the DMZ interface and trace each permitted flow from the public segment to the internal network, then confirm that the flow is logged. If the public components are in a separate cloud account or virtual network, the assessor will want the peering, routing and access policy records for that account.

Assessors test the boundary protection mechanisms themselves, not only the drawing that describes them. They may attempt to reach an internal host from a public-segment system, review whether the rule set denies that path by default, and check that an administrator cannot reconfigure the segment without a recorded change. Organizations should plan for this by keeping rule exports, change tickets and log samples ready in final form, since drafts do not count. Where a requirement is assessed as not applicable because no publicly accessible systems are in scope, the organization must be able to show that the scope excludes them, so the component inventory should be checked against the scope statement before anyone claims that status. Whether a given environment meets these objectives depends on its own design, which an assessor and the organization's security team should confirm together.

What assessors ask for and where SC.L2-3.13.5 findings usually come from

This table compares each of the two SP 800-171A assessment objectives for SC.L2-3.13.5 against the evidence an assessor expects and the findings that most often cause a NOT MET. Read each row as a question the assessor will put to your environment, then check whether your documents and test results answer it in final form.

Assessment area	Evidence the assessor expects	Common findings
Objective 1: Publicly accessible system components identified	Current network diagrams showing internet-facing hosts, load balancers, web and mail servers, and cloud public IP addresses. A list of publicly accessible components tied to the CMMC Assessment Scope.	Public hosts missing from the inventory. Diagrams older than the current cloud or on-premises topology. Public endpoints added by a project team and never recorded.
Objective 1: Key internal boundaries listed	The documented list of key internal boundaries, with the reason each boundary exists and the device or cloud construct that enforces it.	No list exists, or the list names only the external firewall. Internal boundaries between the DMZ and CUI enclaves are not identified.
Objective 2: Public subnetworks separated from internal networks	Firewall rule set exports, showing the DMZ and internal interfaces, and cloud subnet and security group or network ACL exports for each public subnet.	Flat networks where public hosts share a VLAN or subnet with internal systems. Public web servers placed on a segment with direct routes to internal databases.
Objective 2: Rules controlling traffic between zones	Rules showing that traffic from the public zone reaches only the specific services it needs, and that the internal zone initiates only the connections it must.	Rules allowing any-to-internal traffic, often left from testing or added as broad troubleshooting exceptions. Aliases that quietly include internal address ranges.
Testing of separation (both objectives)	Test records from a host in the public zone attempting to reach internal subnets directly, with the result, date and the person who ran the test. Logs of blocked attempts where the platform records them.	No test was run, so the design is asserted but not shown. Tests run once before a rule change and never repeated.
Cloud-hosted public components	Exported subnet definitions, route tables, security group rules and network ACLs, plus evidence that the public subnet has no route to internal subnets except through controlled paths.	Security groups that permit the whole VPC CIDR. Peering or transit routes that bypass the intended DMZ. Console changes not reflected in the exported configuration.
Applicability (N/A) decisions	A documented scope statement showing whether any publicly accessible system exists within the CMMC Assessment Scope. Where none exists, evidence that the scope excludes public-facing assets.	Claiming N/A while a marketing site, email gateway or remote access portal is hosted under the same tenant. An N/A claim with no supporting diagram or inventory.
Configuration and change records	Change tickets and version history for firewall and cloud network rules, showing review and approval of changes that affect the public-to-internal boundary.	Rule changes made directly on devices with no record. Drift between the approved design and the running configuration.

How to implement a DMZ or separate cloud environment for public systems

This sequence moves publicly reachable services out of the internal network and into a separated subnetwork, with every boundary device and traffic path documented so an assessor can confirm the separation for SC.L2-3.13.5.

Inventory every publicly reachable component
The organization's system owner, with input from the IT team, lists every component that accepts connections from the internet or from untrusted partner networks. Include web servers, APIs, mail relays, VPN concentrators, DNS, file transfer endpoints and any cloud load balancers or public IP addresses, including ones created for testing and forgotten later. Confirm the list against cloud consoles, firewall NAT rules and external scan results. The output is a public component inventory with owner, address, protocol and the internal systems each component talks to. Any component not on this list is a gap an assessor will find.
Define the public subnetwork and internal boundaries
The network architect draws the target design: a DMZ or a separate cloud subnet or virtual network for public components, and a named boundary between it and each internal network. Record which direction traffic may flow across each boundary and which ports are needed. Keep the internal boundaries list current, because SP 800-171A treats that list as evidence. The output is a network diagram and a boundary register that name every segment, its purpose and its permitted flows. Confirm the design with the security owner before any hardware or cloud rules are built.
Deploy boundary devices between the segments
The infrastructure team deploys the boundary devices that enforce the design, for example OPNsense as a stateful packet filter with interfaces for the public, DMZ and internal networks. Create aliases for each address group, write rules that pass, block or reject traffic by source, destination, port and protocol, and enable logging on the rules that matter. Keep administrative access to the firewall on a management path, not the public interface. The output is an exported configuration and rule set that matches the boundary register. Confirm by reviewing that no rule permits direct public-to-internal traffic.
Place public services behind a reverse proxy or WAF
The platform engineer moves each public web or API service so that it is reached only through a reverse proxy or web application firewall in the DMZ. For web traffic, Coraza is one open-source option: it is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set and can be integrated with proxies such as Caddy, HAProxy, Traefik or Nginx. Confirm the integration and ruleset with the product documentation and the team's own testing. The output is a proxy configuration, a WAF rule set version and a record of which backends each proxy forwards to.
Restrict the internal side of each boundary
The network team limits what the DMZ can reach inside. Public components should initiate only the connections they need, such as a web tier querying a specific database port on one internal host, and internal systems should not accept unsolicited connections from the DMZ except for those named flows. Remove any shared credentials or management ports that let a compromised public host reach internal hosts. The output is a reviewed set of inbound and outbound rules for each internal boundary, with the reason for each rule recorded next to it.
Validate separation with connection tests
An internal tester, or an independent security tester engaged for the purpose, attempts connections that the design should block: from the public network to internal addresses, from the DMZ to internal ports not on the approved list, and from internal hosts to the public side where that is not needed. The tester also confirms that the permitted flows still work. Record each test with the source, destination, expected result and actual result. The output is a boundary test report that shows which objectives were demonstrated, and any failure must be fixed and retested before the step closes.
Record each step as assessment evidence
The compliance lead collects the outputs from every earlier step into the system security plan and the evidence folder: the public component inventory, the network diagram, the boundary register, the firewall and proxy configurations, the log samples showing denied and permitted traffic, the enterprise architecture documentation and the test report. Each artifact is dated, versioned and kept in final form, because an assessor scores a requirement MET only when the evidence is final. The output is an evidence package indexed to the two SP 800-171A objectives for 3.13.5. Ask any independent assessor which formats and retention periods they expect before collecting.

Evidence that proves public-access separation and how to keep it current

An assessor testing SC.L2-3.13.5 looks for a chain of records: what is public, where it sits, how traffic is controlled at the boundary, and proof that the controls worked on a known date. The cards below cover each record and the routine that keeps it accurate after the environment changes.

Current architecture and network diagrams

Diagrams should show every publicly accessible component, the DMZ or separate cloud environment that holds it, and each path into the internal network. Assessors compare the diagram with the live environment, so a diagram that predates the last firewall or routing change will fail on its own. Record a version number, an approval date and the name of the person who approved it. Confirm that the diagram matches the enterprise security architecture documentation your assessor will also request.

Inventory of publicly accessible components

List every host, load balancer, web application, API endpoint and public DNS record that accepts traffic from outside the organization. Each entry should name the owner, the subnet or cloud account it runs in, and the internal networks it is permitted to reach. This inventory answers the first assessment objective directly. Re-run discovery against the internet-facing address space before each assessment, because forgotten test sites are a common finding.

Firewall and cloud routing configurations

Export the rule sets from perimeter firewalls, DMZ interfaces, security groups and route tables, and keep dated copies. Rules should show the source, destination, port and protocol for each permitted flow between the public tier and internal networks. An assessor will check that no route lets a public subnet reach internal address ranges directly. Store configuration exports under change control so the version in force on any given date can be shown.

Boundary protection hardware and software records

Keep an asset record for each firewall, web application firewall, reverse proxy and cloud network control, with its model or software version, license status and the rule set it runs. For open-source components such as OPNsense for stateful packet filtering or Coraza for web application filtering, record the release in service and the date it was last patched. Assessors use these records to confirm that the mechanisms named in the diagrams are the ones actually deployed.

Change records for the public tier

Every new public service, DNS change, certificate issue, firewall rule addition and cloud route change should carry a ticket with the requester, the approver, the reason and the test performed before go-live. Tie each change back to an updated diagram and inventory entry. Changes made directly in a console without a ticket are the most common reason separation evidence cannot be trusted, so check for them when reviewing logs.

Boundary device audit logs and dated tests

Retain logs from boundary devices showing denied and permitted flows across the public tier, and review them on a set schedule with the review recorded. Pair the logs with dated test results: an external scan confirming that only intended ports answer, and an attempt to reach an internal host from a public subnet that should fail. Keep the test scope, tool version, tester and result together. Confirm your retention period with the assessor, since the rule does not set one in the facts supplied here.

What meeting SC.L2-3.13.5 costs in money and effort

This table lists the cost and effort components of meeting SC.L2-3.13.5, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request, since no price figures are published for this requirement in the supplied research.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it
Subnetwork design and firewall engineering	Internal network team or implementation partner	One-time, with revisions on change	Number of public services, number of internal zones, and whether the design is new or retrofitted
Hardening of public-facing services	Platform engineers or implementation partner	One-time, then recurring patching	Count and type of public services such as web, mail, VPN or API endpoints
Firewall and WAF licenses or subscriptions	Commercial vendor if chosen; none for self-hosted open source	Usually recurring if commercial	Choice of commercial versus open-source tooling and throughput needs
Cloud network construction	Cloud platform fees and engineering time	Setup one-time, hosting recurring	Cloud versus on-premises, number of accounts or VPCs, and egress volume
Evidence collection and upkeep	Internal compliance or security staff	Recurring, tied to change cycle	Frequency of rule changes, logging retention, and how boundary configs are stored
External penetration test or architecture review	Independent testing firm, not the assessor	Recurring, usually annually or after major change	Attack surface size, number of public endpoints, and scope agreed in writing
Assessor sampling and testing	Certified assessor, paid by the organization	Per assessment cycle	Number of boundary devices, rule sets and objectives the assessor samples
Ongoing rule review and change control	Network or security operations staff	Recurring	Frequency of new public services and firewall rule churn
Team training and runbooks	Internal staff or training provider	One-time, with refresh	Staff turnover and number of administrators touching boundary devices

Who owns public-access separation and what partners can take on

The contractor owns SC.L2-3.13.5 in full. The organization decides which system components are publicly accessible, where the subnetworks sit, which internal networks they must be separated from, and who accepts the residual risk. Those decisions belong in the system security plan and the enterprise security architecture documentation, which an assessor will read first. A partner can draft these documents, but the contractor's leadership must approve them and be able to explain them during an assessment.

Inventory of public-facing components: Maintain a current list of web servers, APIs, mail relays, remote access gateways and any other component reachable from the internet, with the owner of each.
Architecture decisions: Choose between a DMZ, a separate cloud subnet or account, or another logical separation, and record the reasoning.
Boundary policy: Approve the rules that govern traffic between the public zone and the internal network.
Evidence ownership: Keep the boundary configuration exports, change records and audit logs current, since they must be in final form at assessment time.
Scoping decisions: If no publicly accessible systems exist in the assessment scope, document that conclusion and its basis, because the assessment objectives can then be scored as not applicable.

Before any assessment, confirm that someone on the internal team can walk an assessor through the diagram, the component list and the rule set without relying on the partner.

Common gaps that fail public-access separation

Assessors test SC.L2-3.13.5 by asking two things: can the organization name every publicly accessible component, and can it show that those components sit in subnetworks separated from internal networks. The gaps below are the ones that most often leave the first answer incomplete or the second answer unprovable.

Undocumented public hosts

Public-facing components often appear through marketing sites, forgotten test instances, or vendor-hosted tools that no one added to the system inventory. The first assessment objective requires identifying every publicly accessible component, so an unlisted host is a failed objective before any network test runs. Build the list from external scans and DNS records, then reconcile it against the asset inventory. Ask who approved each public address and when.

Flat cloud VPCs

A single cloud network with public subnets and private CUI workloads in the same address space means nothing separates them except host-level rules. Assessors look for distinct subnetworks, routing tables and security groups that show the boundary exists at the network layer. Confirm that CUI workloads have no route to an internet gateway and that public tiers reach internal systems only through defined paths.

Management interfaces exposed publicly

Administrative consoles, SSH, remote desktop and database ports sometimes sit on the same public address as a website because they were opened for convenience. This defeats separation even when the web tier is correctly isolated, and it overlaps with the role separation expectations of SC.L2-3.13.3. Check external scans for administrative ports and require that management access comes only through a controlled internal or VPN path.

Stale network diagrams

Boundary diagrams that describe a network from two changes ago fail the evidence test, because assessors compare the documented architecture with what the firewall and cloud configuration actually show. The SP 800-171A evidence list includes the list of key internal boundaries and enterprise security architecture documentation. Tie each diagram revision to a change record, and walk the diagram against live configuration during the review cycle.

Rules without logging

A correct allow rule that no one can later prove existed or matched is weak evidence. Boundary devices should log rule matches so the organization can show which traffic crossed from the public tier and whether anything reached internal networks unexpectedly. Confirm logging is enabled on each rule that passes traffic into or out of the public subnetwork, and that logs are retained and reviewed under the audit requirements.

Shared accounts across environments

When the same administrator accounts, service credentials or identity groups manage both public and CUI environments, a compromise of the public side gives direct reach into the protected side. Separation of subnetworks does not help if the control plane is shared. Assign distinct administrative identities per environment, restrict cross-environment credentials, and document which accounts can change boundary rules.

Questions buyers ask about SC.L2-3.13.5 cost, effort and outsourcing

Does SC.L2-3.13.5 require a DMZ?

No. The requirement calls for publicly accessible system components to sit in subnetworks that are physically or logically separated from internal networks. A DMZ is the most common way to meet that, but a separate cloud environment or a dedicated segment with its own boundary controls can also satisfy it. What matters to an assessor is that the separation is real, documented and tested. Assessors look for a list of publicly accessible components, the boundary devices that enforce separation, and tests showing traffic between the public side and internal networks is restricted as designed.

How long does public-access separation take to build?

The duration depends on how many public-facing systems you run, how tangled your current network is, and how much documentation already exists. Drivers include the number of internet-facing services, whether they already sit behind a firewall, the state of your network diagrams, and how many internal dependencies a public service has, such as a database or directory it calls. Ask any provider for a written, fixed-scope plan with milestones before work starts, and confirm which items are in scope and which depend on your change windows.

Can a partner build the public-access separation for us?

Yes, a partner can plan, implement and document the separation, and DeployOpen does this for self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. The partner prepares the systems and evidence. The organization still owns the control, and only an independent assessor can judge whether the requirement is MET. Check that the partner's written scope names the subnetworks, boundary devices, rule sets and evidence deliverables you need.

What does our team need to supply to a separation project?

A partner will need reliable inputs from your side. Typical items include a current inventory of internet-facing systems, network and cloud diagrams, the owners of each public service, the internal systems those services connect to, change approval paths, and access to your boundary devices and cloud accounts. Your team also owns the decisions about which services are public and which traffic must cross the boundary. Missing inventory data is the most common reason separation work slips, so agree on these inputs in the written scope.

Can we do public-access separation in-house?

Yes, if your staff has network segmentation experience, can build and test the boundary, and can produce the documentation an assessor expects. Many organizations do the design and configuration internally and bring in outside help for documentation, testing or a second review. Open-source options such as OPNsense, which can pass, block or reject traffic by source, destination, port and protocol and log rule matches, and Coraza, a web application firewall for public web traffic, can be run by your own team. Confirm features and fit with each vendor before relying on them.

Does a separate cloud environment count as public-access separation?

It can, provided the public components are placed in an environment that is logically or physically separated from internal networks and the boundary between them is controlled and documented. A separate cloud account or virtual network with restricted peering and explicit rules can meet the objective. Assessors will want to see the network architecture, the list of public components, the controls at each crossing point and tests of those controls. Confirm your cloud environment's scope with your assessor before you assume it qualifies.

How does this requirement affect our POA&M and score?

SC.L2-3.13.5 is a 5-point requirement under the CMMC Scoring Methodology. If it is NOT MET, 5 points are subtracted from the maximum score of 110. Because it is worth more than 1 point, it cannot go on a Plan of Action and Milestones, so it must be MET for a Conditional or Final Level 2 status. Under the scoring rules, an objective assessed as not applicable counts the same as MET, which is why the scope of your public systems must be defined accurately. Confirm the current status of CMMC phases with your contracting officer, since the Department of War suspended Phase II on 13 July 2026.

How DeployOpen scopes, implements and prepares evidence for public-access separation

DeployOpen treats SC.L2-3.13.5 as an architecture and evidence task: first identify which systems are publicly accessible, then separate their subnetworks from internal networks and document the boundary. We implement the open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and we prepare the evidence. Only an independent assessor issues the assessment result.

How we scope

We inventory every publicly accessible system component and record its subnetwork, owner and internet-facing addresses.
We map the key internal boundaries that public components must be separated from, so the assessor can trace each path.
The written scope states what is in the CMMC Assessment Scope, and any component you judge not applicable is documented with reasons for review.

How we build

We design a DMZ or separate cloud environment for public components, with OPNsense rules that deny traffic by default between zones.
We place a web application firewall such as Coraza in front of public web applications, configured with the OWASP Core Rule Set and tuned to your traffic.
We enable logging of rule matches and boundary events so each separation control can be tested and reviewed later.

How we hand over

We deliver the enterprise security architecture diagram, the boundary device configuration exports and the list of key internal boundaries.
We produce test records showing that public components cannot reach internal subnetworks and that the permitted paths behave as documented.
We hand over the evidence in final form, with owners and review dates, so your team can present it to an independent assessor.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, so boundary rules stay current as public services change.
A quote follows from the written scope. Confirm with us which tests and documents are included before you sign.