What CMMC SC.L2-3.13.6 requires for network traffic by default
A defense contractor that handles CUI in its systems must be able to show that its network does not talk to anything it has not been told to talk to. SC.L2-3.13.6 is the CMMC Level 2 requirement that sets this posture: deny all network communications traffic by default and permit only by exception. In practice, every flow that crosses a managed interface is blocked unless someone has identified it, justified it and written a rule for it. The requirement is a 5-point item in the CMMC Scoring Methodology, so if an assessor finds it NOT MET, five points come off the maximum score of 110, and it cannot be moved to a plan of action and milestones (POA&M). Under 32 CFR 170.21, only requirements worth 1 point may go on a POA&M, so this one must be fully MET to reach Conditional or Final Level 2 status.
The requirement adds specifics to SC.L2-3.13.1, which asks only that communications be monitored, controlled and protected at the boundary. SC.L2-3.13.1 can be satisfied by a firewall with broad rules. SC.L2-3.13.6 asks for the stricter default: the rule set starts from deny-all, and each permitted path is an explicit exception. NIST SP 800-171A splits the requirement into two assessment objectives, one for the default deny and one for the exceptions. An assessor will look at the mechanisms that manage traffic at managed interfaces, such as the boundary firewall, the rule base, configuration settings and the audit records of rule matches. A firewall whose last rule is "allow any" fails the first objective regardless of how tidy the rest of the policy looks.
The hardest part is usually not writing the deny rule but inventorying the legitimate flows that the exceptions must cover. Email relays, software update servers, identity services, backup targets, remote administration paths and vendor connections all need a documented business purpose, a source, a destination, a port and a protocol. Teams often find flows nobody remembers, and some of them are needed. Before enabling default deny, confirm the flow inventory with system owners, run the rule set in logging mode, and review the matches. Then ask your assessor, or your implementation partner, what evidence they expect for each exception, since the mechanisms and records you use will define what you can show later.
Which interfaces, systems and third parties fall under the deny-by-default rule
SC.L2-3.13.6 applies wherever network communications enter or leave the CUI system, so the first job is drawing the boundary. The cards below cover the interfaces, internal segments and third-party services that a scoping decision brings under the deny-all, permit-by-exception rule set, and the checks that show each one is covered.
The CUI system boundary
The deny-by-default rule starts at the edge of the system that stores, processes or transmits CUI, not at the edge of the corporate network. Document the boundary in the system security plan with a network diagram that names every path in and out. Ask the assessor to see how each path is enforced and logged. Any path left off the diagram is a path that may not have a deny rule at all.
Perimeter firewalls and managed interfaces
Perimeter firewalls are the most visible managed interfaces, and assessors commonly look at them first. Confirm that the default policy ends in a deny, that each permit rule names a source, destination, port and protocol, and that rule changes go through change control. An open-ended any-to-any rule at the bottom of the list defeats the requirement regardless of how many specific rules sit above it.
Internal segment boundaries
Internal segments that hold CUI, such as engineering file stores, build servers or research networks, need their own deny-by-default boundary. Flat networks where any workstation can reach a CUI server undermine the rule even when the perimeter is tight. Map which segments can talk to each other, then permit only those flows and document the business reason for each one.
Cloud security groups and network access lists
Cloud environments enforce this rule through security groups, network access control lists and private endpoints, and their defaults often allow more than teams expect. Review each CUI workload's inbound and outbound rules, remove broad ranges such as all ports from the internet, and check that egress is restricted as well as ingress. Export the rule set as evidence, since the assessor will test what is actually configured.
Remote access gateways and VPN termination
Remote access gateways are managed interfaces where outside users and devices reach CUI systems, so they need explicit permit rules for named user groups and destinations only. Verify that the gateway itself denies everything else, and that split tunneling rules align with SC.L2-3.13.7. Logging each permitted session at the gateway gives you the audit trail that shows exceptions were actually used.
Third-party hosted services in scope
A third-party service that stores, processes or transmits CUI is part of the system you must justify under SC.L2-3.13.6, even if you do not operate its network. Ask providers for their boundary documentation, the ports and destinations your integrations need, and evidence of their own deny-by-default controls. Services that handle no CUI can sit outside the boundary, but the scoping decision must be written down and defended. Confirm with your assessor how they expect provider evidence to be presented.
How an assessor tests deny-by-default and permit-by-exception
This table maps the two SP 800-171A assessment objectives for SC.L2-3.13.6 to what an assessor examines, the evidence they ask for, and where organizations commonly fail. Read it as a preparation checklist: each row shows what the assessor will look at and what your evidence should already show before the assessment begins. The main takeaway is that a default-deny posture is proven by rule sets and their logs, not by a policy statement.
| Assessment focus | What the assessor tests | Evidence to have ready | Common finding |
|---|---|---|---|
| Default deny | Whether all network communications are denied unless a rule explicitly permits them, at each managed interface in scope | Exported rule set for each boundary device, with the final rule showing a deny-all action and the default policy setting | Default policy set to allow, or a deny rule that sits below a broad permit rule and never matches |
| Permit by exception | Whether each allowed flow traces to a documented business or system need, limited by source, destination, port and protocol | Rule register linking each permit rule to an owner, a purpose and an approval record, plus the system security plan boundary diagram | Permit rules with no stated purpose, or rules that name whole subnets and all ports where a specific service was needed |
| Boundary protection procedures | The written procedure for adding, changing and removing rules, and whether teams follow it | Change tickets for recent rule changes, with approval and review dates, and the procedure document version in effect | Procedure exists but rule changes were made directly on the device without a ticket |
| Configuration settings | Live settings on firewalls, routers, cloud security groups and proxies that enforce the deny-by-default posture | Configuration backups or exports taken on a set schedule, and a comparison against the approved baseline | Settings differ between the baseline document and the live device, or temporary rules were never removed |
| Audit records | Whether denied and permitted traffic events are logged, retained and reviewed at the managed interfaces | Sample log entries for blocked traffic and for a permit rule match, plus evidence of review or alerting | Logging is enabled on some interfaces only, or logs exist but no one reviews denied connections |
| Sampling of rules | A selection of rules chosen by the assessor, checked for purpose, scope and whether traffic was actually observed | Complete rule export so any sampled rule can be traced, with hit counts or match logs where available | Rules that have never matched traffic for long periods remain enabled without a documented reason |
| Any-any rules | Whether any rule permits all sources, all destinations, all ports and all protocols, or sits high enough to override the deny rules | A search or report showing no unrestricted permit rules, or each one documented with a compensating scope | A single permissive any-any rule, often added during troubleshooting and left in place, is a typical failure because it defeats the deny-by-default objective |
Implementing deny-all, permit-by-exception at managed interfaces
This sequence turns a general statement of intent into a documented rule set that denies all traffic by default and permits only named, justified flows at each managed interface. The output is evidence an assessor can trace from every allowed flow back to a business reason and a rule.
Inventory every network flow in scope
Map the system boundary, including the external boundary and key internal boundaries, and list every communication path that carries or could carry CUI. Record source, destination, port, protocol, and the system or service that initiates each flow. The team responsible for network operations typically builds this inventory with the system owner, using device configurations, traffic captures, and cloud flow logs. The step is done when the inventory reconciles against the network diagram in the system security plan and an owner signs off on each flow as known.
Document each exception with a business justification
For every flow that must be allowed, write an exception record that names the business purpose, the data type involved, the source and destination, the approving owner, and the review date. Flows that cannot be justified are removed from the design rather than carried forward. Records are kept with the configuration baseline so an assessor can see why each exception exists. The output is an approved exception register that matches the inventory one to one.
Set the default deny rule
Configure each managed interface so that the final rule in its rule set denies all traffic that no earlier rule permits, in both directions where the device supports it. Confirm the policy applies to traffic crossing the boundary and not only to traffic addressed to the firewall itself. Test the default with traffic that matches no exception to show it is dropped or rejected. The output is a tested default-deny policy on each interface, with the test results saved.
Apply permit rules at each managed interface
Translate each approved exception into a permit rule on the specific interface where the flow crosses, using narrow source, destination, port, and protocol values and address aliases for groups of hosts. Avoid broad any-to-any permits and place the rules above the default deny. Store the rule set as configuration under version control so each change is traceable. The output is a rule set in which every permit maps to exactly one exception record.
Enable logging of rule matches
Turn on logging for the default deny and for each permit rule so that allowed and blocked traffic both leave a record. Forward those logs to the central audit log store, where retention and protection follow the audit and accountability controls. Check that a test flow appears in the logs with the expected rule identifier. The output is a verified log trail showing both permitted and denied communications at each managed interface.
Validate the rule set against the exception register
Compare the live configuration on each device with the approved rule set and the exception register, then test a sample of permitted and denied flows from both sides of each boundary. Look for rules that exist without an exception, exceptions with no rule, and permits that are wider than the justification. Correct gaps through change control and record the findings. The output is a validation report that an assessor can reproduce.
Review rules on a defined schedule
Set a recurring review of the exception register and the live rule sets, with a named owner, and trigger an extra review after system changes, new integrations, or incidents. Remove exceptions whose business reason has ended, and document each decision. The review should also confirm that log review is happening, since rule matches only reduce risk when someone reads them. The output is dated review records showing that the rule set still matches the current system boundary.
How to build an exception register that survives an assessment
Every allow rule at a managed interface should trace back to a documented exception, and the register is where that trace lives. For SC.L2-3.13.6, an assessor starts with the deny-by-default posture and then asks for the exception that justifies each permitted flow. Each entry should record the business purpose, a named owner accountable for the flow, the source and destination, the port and protocol, and an expiry or review date. The owner matters as much as the technical fields, because an assessor will ask who approved the traffic and who would notice if it stopped being needed. Confirm with your own assessor which fields they expect to see in the register and whether they want approvals stored as signed records.
Firewall rule sets become reviewable when rules reference named aliases instead of raw addresses. In OPNsense, aliases group hosts, networks and ports into objects with descriptive names, so a rule such as permitting a patch server to reach a fixed set of update sources reads as one line tied to a register entry. Changing an address then means editing one alias, and the register and the rule set stay aligned. Keep alias names stable and map each alias to a register ID, so a reviewer can move from a live rule to its justification without guessing. Review the rule log view periodically to check that the rules still match real traffic, since a rule that never matches is a candidate for removal.
Undocumented exceptions are the most common finding because they accumulate quietly. A rule added during a troubleshooting session, a vendor connection that was never written down, or a legacy permit that outlived its project will all pass a casual look at the rule set, yet none has an owner or review date to show it is still justified. Before an assessment, reconcile the live rule set against the register, retire any rule with no entry, and set a recurring review that revalidates each exception. Ask your implementation partner to prepare the reconciliation and evidence, but keep the approval decisions with the system owner, since the organization owns its controls and only the independent assessor judges whether the evidence meets the requirement.
Evidence that proves deny by default and permit by exception
An assessor testing SC.L2-3.13.6 looks for proof of two things: that traffic is denied unless a rule allows it, and that every allowed path was deliberately approved. The cards below cover the artifacts that show both, and how to keep them in final form between assessments.
Exported rule sets with default deny
Export the complete rule set from each managed boundary device, including the final catch-all rule that blocks all traffic not matched above it. Confirm the export is taken from the running configuration, not a planning document, and record the date and the account that produced it. An assessor will check that the default action is deny and that no permit-any rule sits above the exceptions. Confirm which interfaces, cloud security groups and host firewalls are in scope so the export covers every managed interface.
Exception register with approvals
Keep one register listing every permitted flow, with source, destination, port, protocol, business purpose, data classification, owner, and the approver's name and approval date. Each rule on the firewall should trace to a register entry, and each register entry should trace to a rule. Assessors often sample a rule at random and ask for its approval, so an exception without a signed approval is a finding.
Configuration baselines
Maintain a documented baseline for each boundary device that records the approved default policy, management interface restrictions, logging settings and alias definitions. Store the baseline under version control so differences from the running configuration are visible. Confirm with your assessor which level of detail they accept, since a baseline that only lists the deny-all statement without the settings that enforce it is unlikely to demonstrate the control.
Change records for rule edits
Every rule addition, modification or removal needs a change record that states the reason, the requester, the security review, the approver, the implementation date and the rollback step. Compare the change log against the exception register monthly. A rule that appears on the firewall without a matching change record is the kind of gap that undermines an otherwise well-designed deny-by-default posture.
Log samples showing matches and denials
Retain log extracts that show permitted flows matching exception rules and denied flows hitting the default deny rule. Logs from the firewall should include the rule identifier so a reviewer can link each event to an approved exception. Confirm log retention periods with your own audit logging requirements, and verify that logs are protected from modification. Denied traffic samples prove that the default rule is active, not just present in the configuration.
Periodic review records
Record a scheduled review of the full rule set against the exception register, with the reviewer, date, findings and disposition of each stale or unexplained rule. Remove exceptions whose business purpose has ended and document the removal. Keep the review cadence you define in your system security plan, and confirm that the reviews are signed and dated so they remain final records rather than working drafts.
Using OPNsense and Coraza to produce rule and log evidence
OPNsense is a firewall platform built on FreeBSD, and its core is a stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol. For SC.L2-3.13.6, the usual design starts with a block-all default at each managed interface, then adds narrowly scoped pass rules for each business flow that the system documents as necessary. OPNsense is licensed under BSD-2-Clause, which permits use and modification with notice retained, so licensing does not limit its use in a CUI environment.
- Default deny rule: A final block rule at each interface shows the deny-by-default half of the assessment objectives.
- Aliases for address groups: Named aliases for hosts, networks and ports make each exception readable and easier to review against the system security plan.
- Per-rule logging: Enabling logging on rules produces match records that show traffic was permitted or blocked by a specific rule.
- Live log view: Reviewers can filter the live log to confirm that blocked traffic is recorded and that exceptions match approved flows.
- Configuration export: A saved configuration backup gives assessors the rule set as it stood at a point in time.
Confirm with your environment whether OPNsense fits your boundary design, the throughput you need, and whether your log retention meets the audit and accountability requirements you already assessed.
Coraza is a web application firewall written to be compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects HTTP requests and responses for patterns such as SQL injection, cross-site scripting and code injection. Coraza is licensed under Apache-2.0, which is a permissive license with an express patent grant. It is not a network packet filter, so it does not replace the rules at the perimeter. Its role is to filter what is allowed through a proxy or gateway. Coraza provides integrations for Caddy, HAProxy, Traefik and Nginx, and the choice of proxy shapes how rules are deployed and logged.
- Rule set control: The OWASP Core Rule Set and any custom rules are versioned files, which gives assessors a concrete ruleset to review.
- Audit logging: Coraza audit logs record matched rules for each transaction, which supports the tracing and review of blocked requests.
- Proxy integration: Deploying Coraza in a proxy you already run keeps application-layer filtering on the path that exposes the system.
- Tuning records: Documented exceptions and false-positive decisions show a managed process rather than an unmanaged default.
- Scope limits: Coraza does not control arbitrary network protocols, so it cannot evidence rules for non-HTTP traffic.
Confirm with your environment which proxy you will use, how rule updates are tested and approved, and how Coraza logs reach your central log system.
Assessors test SC.L2-3.13.6 by examining configuration and records, so the question is which artifacts each tool gives them. The table of evidence below is a starting point. It does not establish compliance on its own, because the organization must show that the rules match its documented boundary and that the records are retained and reviewed. Evidence needs to be in final form, not drafts, to count toward a MET determination.
- Rule configuration: Exported OPNsense rules and aliases show the deny-by-default and exception design.
- Rule match logs: OPNsense logs and Coraza audit entries show what traffic was permitted or blocked.
- Change records: Tickets or commits that approve each new exception link rule changes to a business reason.
- Review records: Dated log reviews show that someone examined blocked and permitted traffic on a defined schedule.
- Architecture diagram: A diagram that matches the managed interfaces and the rule set helps assessors trace each boundary.
Confirm with your assessor and your system security plan which records they will accept and in what format before you build the evidence trail.
Both tools are open source, which lowers the cost of software but does not remove other costs. The license governs how you may use, modify and redistribute the code. It does not decide whether the tool meets a control or whether your deployment is supportable. Under BSD-2-Clause, OPNsense can be used freely if you keep the copyright notice and disclaimer when you redistribute it. Under Apache-2.0, Coraza can be used, modified and distributed under the license terms, and it includes a patent grant from contributors. Neither license includes a warranty, so the organization or its implementation partner owns configuration, patching and support decisions.
- One-time costs: Design, configuration, rule tuning and initial testing are paid once, through internal staff or an implementation partner.
- Recurring costs: Patching, rule updates, log storage, log review and periodic testing recur for the life of the system.
- Support model: Confirm whether you will rely on community support, a commercial support contract or internal staff.
- Vendor status: Ask the implementation partner to state in writing which parts of the stack they support.
- Quote scope: Ask for a fixed scope covering rules, logging, testing and handover documentation.
Confirm the current license text and any third-party components with the project pages before you rely on them in a formal submission.
What meeting SC.L2-3.13.6 costs in tooling, engineering and upkeep
This table lists the cost components of meeting SC.L2-3.13.6, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to shape a quote request: the largest variable is usually engineering time for flow inventory and rule writing, not the software itself. No figures are given because none were supplied for this requirement; ask vendors and providers for their own written estimates.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Firewall hardware or licenses | Hardware vendor or firewall licensor | One-time for appliances, recurring for commercial subscriptions | Throughput needs, number of managed interfaces, high availability design. Open-source platforms such as OPNsense (BSD-2-Clause) remove license spend but not hardware or support decisions. |
| Flow inventory and traffic mapping | Internal engineers or implementation partner | One-time, with periodic refresh after changes | Number of systems, cloud accounts and undocumented data flows. Clean asset inventories shorten this work. |
| Rule writing and deny-by-default policy | Internal network or security engineers | One-time build, recurring on every change | Count of permitted flows, use of aliases for address groups, and how strictly change control is enforced. |
| Log storage and review | Internal operations, SIEM or log platform provider | Recurring | Logging volume from rule matches, retention periods set by the organization, and how often denied traffic is reviewed. |
| Web application filtering (where used) | Internal engineers or implementation partner, plus any rule set maintainers | One-time setup, recurring tuning | Number of public applications and false positives. Coraza (Apache-2.0) is open source, so cost falls mainly on configuration and tuning. |
| External testing or independent review | Security testing provider or independent reviewer | Recurring, typically on a schedule | Scope of the boundary, frequency of rule changes and whether results feed the self-assessment. Ask for a fixed-scope written proposal. |
| Assessor sampling effort | Internal staff who produce evidence for the assessor | Recurring at each assessment cycle | Quality of exported rule sets, change records and log samples. Assessors test the configured mechanisms, so evidence must be final form. |
Who owns the rule set, who prepares evidence and who assesses it
The organization is accountable for SC.L2-3.13.6 because the deny-by-default posture is a business decision about which communications the system needs. Leadership, the security function and system owners decide what traffic is necessary, who approves each exception and how long an exception stays in place. The contractor also owns the system security plan entry that describes the boundary and the rule philosophy, and it is the party that signs any affirmation. Ownership does not require doing the configuration by hand, but it does require that someone inside the company can explain every permitted flow and the reason it exists.
- Written policy: A boundary policy that states deny-all as the default and defines who may request a permit-by-exception rule.
- Exception approval: A named approver for each exception, with a business justification and a review date.
- System security plan: A description of the managed interfaces and how the rule set governs them.
- Rule set decisions: Records showing why each allowed source, destination, port and protocol is needed.
- Accountable staff: Internal people who can walk an assessor through the rules without relying on a vendor.
Before engaging anyone, confirm that your own staff can state the purpose of every permitted flow in the rule set.
An implementation partner can do the technical groundwork that the contractor often lacks time or staff to complete. That work typically includes inventorying traffic flows across managed interfaces, drafting the rule sets on the firewall and proxy, documenting the configuration and collecting the logs that show rules are working. The partner prepares the system and the evidence, but the contractor must adopt and approve the result. Under an open-source approach, the partner might build the rules in a stateful packet filter such as OPNsense, and configure logging of each rule match so the reviewer can see deny and permit events. Any engagement should be fixed in writing with defined deliverables.
- Flow inventory: A list of the communications that cross each boundary, gathered from configuration review and traffic observation.
- Rule build: Deny-by-default rules and exception rules written as code or exported configuration.
- Configuration evidence: Exported settings, change records and screenshots taken from the live system, dated and versioned.
- Log validation: Test traffic that proves blocked flows are denied and logged.
- Documentation handover: Runbooks that let the internal team maintain and review exceptions after the engagement ends.
Ask the partner which deliverables are evidence in final form and who signs off on each one.
Assessment is the point where independence matters. Under the CMMC framework, Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Level 2 self-assessments are performed by the organization against NIST SP 800-171A, and the assessor, whether internal or external, must test the objectives directly. The SC.L2-3.13.6 objectives are denying traffic by default and allowing it by exception, so the assessor examines configuration settings, boundary procedures and audit records at the managed interfaces. Assessors cannot design or configure the controls they are judging, and the organization must not allow its consultant to act as the assessor on the same engagement.
- Objective testing: The assessor checks each of the two objectives against evidence in final form.
- Independent sampling: The assessor chooses which rules and logs to review rather than accepting the partner's selection.
- Consultant limits: Consultants may prepare for the assessment but may not perform or influence the scoring decision.
- Scoring outcome: Only the assessor's determination, or the organization's own self-assessment record, sets the requirement to MET.
- Current status: Confirm with the DoW CIO and the rule text which assessment type applies to your contract, because the Phase II certification requirement has been suspended.
Confirm in writing that the partner and the assessor are separate parties with no shared role on the engagement.
Where deny-by-default programs usually fail review
Most failed reviews of SC.L2-3.13.6 trace back to a few recurring gaps rather than a missing product. The cards below cover the rule set itself, the exceptions behind it, the logging that proves it, the cloud layer assessors often overlook, and the review cycle that keeps the rules honest after the assessment.
Broad any-any rules from migration
Rule sets carried over from an older firewall often keep permissive entries such as any source to any destination on any port, placed above the specific rules. Those entries make the default-deny stance meaningless for the traffic they match. Closure: export the full rule base, flag every rule with any in source, destination or port, and either remove it or replace it with a named alias and a documented business reason. Confirm the final order with a test from each side of the boundary.
Exceptions with no owner or reason
Permit-by-exception only works if each exception can be traced to a stated need, an approver and an expiry. Many environments have allow rules named after a former project or with no description at all. Closure: give every permit rule a description field that records the business purpose, the system owner, the approval reference and a review date, and reject any rule that cannot meet that standard during change control.
Rules without logging
An assessor testing the second objective of 3.13.6 looks for evidence that traffic is actually permitted only where an exception exists. Rules that do not log, or logs that are never reviewed, leave no proof. Closure: enable logging on the default deny rule and on each permit rule for CUI boundaries, forward the records to the central log store, and show a sample of logged denies and permits in the review package. Confirm the retention period with your audit policy.
Cloud security groups outside the review
Teams often manage cloud security groups, network access control lists and virtual firewalls through separate consoles, so they never reach the firewall review. A permissive group attached to a CUI workload can defeat the boundary the on-premises firewall enforces. Closure: inventory every cloud construct that filters traffic into or out of the CUI environment, bring it under the same rule standard and review cycle, and include exported configurations in the assessment evidence.
No periodic rule review
Rule sets drift as systems change, and a rule that was justified two years ago may now serve nothing. Without a scheduled review, exceptions accumulate and nobody can say which ones are still needed. Closure: set a recurring review of every permit rule with a named reviewer, remove rules that no longer match an active need, and keep dated records of each review. Ask your assessor which review evidence they expect for your system size.
Questions buyers ask about SC.L2-3.13.6
Can SC.L2-3.13.6 go on a POA&M?
No. SC.L2-3.13.6 is worth 5 points, and under 32 CFR 170.21(a)(2) only requirements worth 1 point may appear on a plan of action and milestones. It must be MET for the organization to reach Conditional or Final Level 2 status. Because a NOT MET result subtracts 5 points from the maximum score of 110 under the scoring methodology in 32 CFR 170.24, a gap here can also pull a score below the level a contract requires. Plan the deny-by-default rule set and its evidence before the assessment window, not after it.
Is a self-assessment enough for SC.L2-3.13.6 right now?
For most contracts today, a Level 2 self-assessment is the path the Department of War currently describes. On 13 July 2026 it suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO's About CMMC page says implementation may only require self-assessments at Levels 1 and 2, while the eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule. Confirm the current requirement with the contracting officer for each solicitation. A self-assessment still has to test SC.L2-3.13.6 against its two assessment objectives, and the result must be accurate because it is posted to SPRS.
What drives the effort to implement SC.L2-3.13.6?
The main driver is the number of network flows that cross managed interfaces. Each flow between zones, to the internet, to cloud services and to remote users needs a documented business reason, a named source, destination, port and protocol, and an explicit permit rule. The rest of the rule set must end in a deny. Effort rises when flows are undocumented, when legacy systems need broad access, when there are many cloud accounts or sites, and when no one owns the rule review. Effort falls when the enclave is small, traffic is already inventoried, and rules are managed as code with logs reviewed on a set schedule. Assessors also look for the audit records that show denied and permitted traffic, so logging design counts as part of the work.
How long does preparing SC.L2-3.13.6 take depending on the number of flows?
No researched figure exists for preparation duration, so treat any number from a vendor with caution. The practical driver is flow count. An illustrative case: an enclave with a few dozen documented flows, one internet egress point and a single firewall can be inventoried and rule-tested in a short sprint, while an environment with hundreds of undocumented flows across several sites and cloud accounts needs discovery, owner sign-off and staged cutovers that take considerably longer. Ask any provider to break the timeline into flow discovery, rule design, testing in a non-production copy, change approval, production cutover and evidence collection, and to state which of those steps assume your staff are available.
What should a fixed-scope quote for SC.L2-3.13.6 include?
A fixed-scope quote should name the boundary and managed interfaces in scope, the flow inventory it covers, the firewall or gateway platforms, and the number of rule sets to be built and tested. It should list deliverables such as the documented deny-by-default policy, the allow-by-exception rule register with owners and justifications, test records, logging configuration and the evidence package for the assessment. Ask who performs each step, what the client must supply, what happens if discovery finds more flows than expected, and how changes to scope are priced. Ask whether ongoing rule review and log review are one-time or recurring. Remember that DeployOpen prepares systems and evidence. The organization owns its controls, and only the independent assessor issues the result.
Can an in-house team implement SC.L2-3.13.6 without a partner?
Yes, an in-house team can implement it if it has people who understand the network architecture, can build and test rules on the firewall platform, and can run change control. The requirement is operational, not a product purchase, so the work is mostly inventory, rule design, testing and evidence. Teams with a stable network and a clear owner for firewall rules often manage it alone. Outside help is most useful when the flow inventory is incomplete, when several cloud and on-premises boundaries must be aligned, or when the team has no capacity to run the review cycle. Whichever route you choose, the organization still owns the control and the assessor still tests it independently.
Which open-source tools can produce the evidence for SC.L2-3.13.6?
Two open-source components address different parts of the requirement. OPNsense, under the BSD-2-Clause license, is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, with aliases for address groups and an option to log each rule match. Those rule definitions and logs can show the deny-by-default posture and the permitted exceptions. Coraza, under Apache-2.0, is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, with integrations for Caddy, HAProxy, Traefik and Nginx. It addresses attacks at the application layer, which is a separate concern from network-layer default deny. Confirm with each vendor which logging and export options your version supports, and check that the configuration can be exported and kept under change control.
How DeployOpen scopes and prepares deny-by-default evidence
DeployOpen plans, implements and hardens the self-hosted open-source firewall and proxy layers that enforce deny-by-default at managed interfaces, inside your own cloud accounts, data centers or air-gapped networks. Engagements start with a written scope that names each managed interface, each zone and each enforcement point in scope, such as an OPNsense firewall at the CUI enclave edge, a Coraza web application firewall in front of a CUI portal, or the reverse proxies that sit between them. The scope also states which rules, aliases and logging settings will be delivered, and what the client will own afterward. Work follows that scope and the deliverables and timelines agreed before work begins.
On the implementation side, the work is building a default-deny policy on each enforcement point and then recording every permitted flow as an entry in an exception register. That register lists the source and destination aliases, the port and protocol, the business justification, the approving owner and a review date for each exception. Rule logging is enabled for permitted and blocked matches so the client can show that traffic is only passing where an approved entry says it should. DeployOpen configures these settings and documents them, and the client's security owner approves each exception. Confirm with the client's own environment which change-control process applies to firewall rule changes, since it affects how quickly exceptions can be added or retired.
DeployOpen prepares the configuration exports, rule listings, register entries, change records and log samples that show the two assessment objectives for SC.L2-3.13.6 are met, and it can run a pre-assessment review of that evidence against NIST SP 800-171A. DeployOpen does not issue assessments, attestations or certifications. A C3PAO or other authorized assessor makes the determination, and the organization owns its controls and the final evidence. Ask any partner to state in writing which evidence is delivered, who holds the exception register after handover, and how the register will be reviewed on a recurring basis.
