03.13.06 deny by default network traffic: NIST 800-171

What 03.13.06 requires: deny by default network communications

If a contract or assessment requires NIST SP 800-171, requirement 03.13.06 asks you to deny network communications traffic by default and allow only the traffic you have specifically permitted. In plain terms, nothing should be able to reach into or out of a system that handles CUI unless someone decided it should, wrote down why, and scoped the exception as narrowly as the business need allows. The requirement comes from the SP 800-53 Rev. 5 control SC-7(5), which NIST tailored into the Rev. 3 catalog. Rev. 3 keeps the same idea as Rev. 2 requirement 3.13.6, and NIST's change analysis classifies the difference as editorial only.

The risk it addresses is the unneeded path. Every open port, permissive rule, forgotten management service or outbound route that nobody currently uses is a way for an attacker to reach CUI or a way for data to leave without anyone noticing. The requirement does not prescribe a product, a rule count, a vendor firewall or a particular architecture. An assessor will look for evidence that a default-deny posture exists in the system design and configuration, that the permitted flows are defined, and that the mechanisms enforcing them at managed interfaces behave as documented. Ask your assessor which documents they expect to see, and confirm the scope of your managed interfaces before the assessment starts.

What usually makes this hard is inheritance. Legacy applications, vendor integrations, backup jobs and administrative tools often rely on flows that no current document describes, and the people who set them up may have left. Before you tighten any rule, inventory the flows that actually occur, record the business owner and reason for each one, and mark the ones you cannot justify. Rev. 3 treats the change as editorial, but CMMC Level 2 still assesses this practice under the Rev. 2 numbering as SC.L2-3.13.6, so DoD contractors should confirm which version their contract and assessor reference before mapping their evidence.

Which network paths count toward deny by default

Before writing a single deny rule, the assessor's first question is which traffic is inside the scope of 03.13.06. The paths below are where scope is most often drawn too narrowly, and each one changes which interfaces need a default-deny policy and which exceptions must be documented.

CUI enclave boundary

The enclave edge is where the default-deny policy begins. Every path that carries CUI into or out of the enclave must cross a managed interface where traffic is blocked unless a rule permits it. Confirm the enclave diagram in the system security plan matches the firewall rule base, because an undocumented flow through a shared switch or VPN concentrator is a finding waiting to happen.

External managed interfaces

Internet-facing firewalls, proxies and gateways are the most visible managed interfaces. Start with a rule set that drops everything not listed, then add only the protocols and destinations the business needs. OPNsense rules pass, block or reject by source, destination, port and protocol, and the option to log each rule match gives you evidence that the default action is working.

Key internal managed interfaces

Internal segmentation between the CUI enclave and general corporate networks, development zones or shared server farms is also in scope where those segments are managed interfaces. Many assessments fail because internal firewalls allow broad any-to-any traffic for convenience. Map each internal boundary, then write rules that permit only the specific flows the enclave needs.

Cloud security groups and virtual networks

In cloud environments, security groups, network access control lists and virtual network peering define the boundary. Default-allow security groups created during provisioning are a common gap. Export the effective rules for every subnet holding CUI, confirm the default inbound action is deny, and check that peering and transit routes do not bypass the enclave boundary.

Remote access paths

VPN gateways, zero-trust access proxies and jump hosts that let staff or contractors reach CUI systems from outside are boundary crossings, even when the user is authenticated. Each remote path needs its own allow rule that names the users, destinations and ports it permits. Confirm that split tunneling and personal devices cannot reach the enclave through a path that skips these rules.

Third-party and management networks

Vendor connections, managed service provider tunnels and out-of-band management networks often sit outside the normal review process. Treat each as a documented exception with a named owner, a specific source and destination, and an expiry or review date. Management interfaces such as hypervisor consoles and firmware update channels should be reachable only from administrative subnets, and that restriction should appear in the rule base and the assessment evidence.

How an assessor tests deny by default traffic

This table maps each part of the SP 800-171A Rev. 3 assessment for 03.13.06 to what the assessor examines, interviews or tests, and the finding that usually appears when the control is weak. Use it to prepare evidence before an assessment, since the same artifacts appear in every row.

Assessment element	What the assessor looks for	Common finding
Determination statements	Two statements check that network traffic is denied by default and allowed only by specific exception, using examine, interview and test methods	Evidence covers only one of the two statements, so the assessor cannot conclude the requirement is met
Examine: boundary protection procedures	Written procedures that describe how rules are requested, approved, reviewed and removed at managed interfaces	Procedures exist but do not describe how exceptions are approved or retired
Examine: system design documentation	A diagram or narrative showing every managed interface and the default-deny posture applied to each	Design documents show flows that the live rule set does not reflect
Examine: configuration settings	Exported firewall rule sets with a final deny rule, and no rule that permits all sources, destinations or ports	An allow-any rule, often left from troubleshooting, sits above the deny rule
Examine: system audit records	Logs showing rule matches for permitted and blocked traffic, retained and reviewable	Rules exist but no logs of rule matches can be produced for the assessment period
Interview: boundary protection staff	Staff explain how they add, change and remove exceptions and how they confirm a rule is still needed	Staff describe exceptions as temporary, yet no expiry or review record exists
Interview: security and system developers	Owners explain which traffic the application needs and confirm the rule set matches that need	Developers request broad ports during build, and the rules are never narrowed before release
Test: traffic management mechanisms	The assessor attempts traffic that should be blocked and confirms the mechanism denies it, and that permitted traffic still passes	An undocumented exception allows a flow that no design document or approval record explains

Implementing default deny in the order an assessor will follow

This sequence turns the requirement to deny network traffic by default into a documented, testable state at every managed interface. Each step produces an artifact an assessor can examine, interview against and test, so the evidence trail matches the way SP 800-171A Rev. 3 frames 03.13.06.

Inventory every managed interface
Start by listing each point where the system's communications cross a managed boundary: internet edges, links to other enclaves, cloud network boundaries, VPN concentrators, and internal segments that hold CUI. For each interface, record the device or service that enforces traffic control, the network segment on each side, and the business purpose that justifies the connection. The output is an interface inventory that the system security plan can reference by identifier. The step is complete when someone outside the project team can trace every CUI path to a listed interface.
Set deny-all as the default policy
At each inventoried interface, configure the enforcing device so that traffic not matched by an explicit allow rule is blocked. In OPNsense, for example, this means a final block rule with logging on each interface, and the configuration is exported and version controlled. Record the default policy for each interface in the configuration baseline so it can be compared against the live state later. The step is complete when a test connection that matches no rule is blocked at every interface in the inventory.
Build allow rules from documented flows
For each permitted communication, write an allow rule that names the source, destination, port and protocol, and link it to a documented data flow. Each rule should have an owner who can explain why the flow exists and a short justification tied to a business or system need. Use address aliases for groups of hosts so the rule set stays readable. The output is a rule register that maps every allow rule to its flow, owner and justification. The step is complete when no allow rule exists without a matching entry in the register.
Enable logging of rule matches
Turn on logging for allow and deny rules at every enforcement point and forward those logs to the central audit store. Confirm that a sample of permitted and blocked connections appears with the rule identifier, timestamp and addresses. Where an enforcement point is managed by a cloud provider, record which flow logs are available and how they are retained. The output is a logging configuration record and a test log extract. The step is complete when an assessor can pick a rule and find its recent matches in the log store.
Verify the live configuration against the baseline
Compare the running rule sets with the exported baseline and the rule register. Look for rules that exist in production but not in the register, allow rules that are broader than the documented flow, and interfaces where the default deny is missing. Use the configuration monitoring in the wider environment to catch drift between reviews. The output is a verification report with each discrepancy resolved or accepted by the rule owner. The step is complete when the live state matches the register and the discrepancy log is closed.
Review and retire exceptions on a set cadence
Assign each exception a review date set by the organization's own policy, then have the owner confirm that the flow is still needed. Remove rules for flows that have ended, and tighten rules whose scope has grown. Record each decision in the exception register with the reviewer and the date. The output is a dated review history that shows the exception population is actively managed. The step is complete when every exception has a recorded review within the cadence the organization defined in its policy.
Record the system security plan references
Connect the artifacts from the earlier steps to the system security plan so the requirement can be traced from the plan to the evidence. Reference the interface inventory, the default deny baseline, the rule register, the logging configuration and the review history by identifier, and describe how the organization assesses each of the two determination statements in SP 800-171A Rev. 3. Confirm with your assessor which artifact formats they expect. The output is a traceability entry for 03.13.06 that an assessor can follow without interviewing the project team. The step is complete when each artifact in the chain has a stated location and an accountable owner.

Evidence that passes 03.13.06

An assessor testing 03.13.06 wants proof that traffic is denied unless someone decided otherwise, and that the decision is documented, approved and reviewed. The cards below cover the artifacts that connect the written policy to the rule sets actually running at each managed interface.

Boundary protection policy and procedures

The written policy states that network traffic is denied by default and allowed only by documented exception. The procedures name who builds, approves and reviews boundary rules and how a rule is tested before it goes live. Assessors examine this document first, so it must match what the firewalls really do. Review it at least once a year and after any change to the network architecture, and confirm the owner has signed the current version.

Managed interface diagram

A current diagram shows every managed interface where the system boundary is enforced, including internet edges, cloud security groups, VPN concentrators and links to other systems that handle CUI. Each interface should be tied to the rule set that controls it. Assessors compare the diagram against live configuration, so unlisted gateways are a common finding. Regenerate or re-verify the diagram after every change to a managed interface.

Exported rule sets showing default deny

Export the running rule sets from each managed interface and confirm the final rule is a deny-all for traffic not explicitly permitted. For a stateful packet filter such as OPNsense, the export should show pass rules by source, destination, port and protocol, with aliases used for address groups. Keep dated exports so the assessor can see how the rule base looked during the assessment period, not only today.

Exception register with owners and approvals

Every allow rule that is not part of the baseline needs a register entry naming the business reason, the data or system involved, the rule owner, the approver, the expiration or review date, and the compensating controls. Assessors sample entries and trace each one to a live rule. Stale exceptions with no owner are a frequent finding, so set a review date for each entry and close any exception that no longer has a business need.

Rule-match logs and review records

Logging each rule match, or at least denied and exception traffic, provides evidence that boundary decisions happen and are reviewed. Keep the log retention period your audit and policy require, and record who reviewed the logs, when, and what they found. OPNsense can log rule matches for review in its live log view, but confirm that exported and centrally stored logs are complete before relying on them for an assessment.

Change records for rule modifications

Each change to a boundary rule should have a ticket or change record covering the request, the impact analysis, the approval, the implementation time and the test performed after the change. Assessors use these records to confirm that no rule was added outside the approved process. Compare the change log against the exported rule sets at each review, because any rule present in the configuration without a record is an exception the assessor will question.

What meeting 03.13.06 costs in money and effort

This table breaks down the cost components of enforcing deny-by-default network communications, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to build a quote request and to decide which parts to keep in-house or outsource.

Cost component	One-time or recurring, and who is paid	What drives it up, and what to ask for in a quote
Boundary hardware and firewall licenses	One-time for hardware, recurring for commercial license or support. Paid to the vendor or hardware reseller. Open-source options such as OPNsense can remove license spend but still need hardware and support time.	Number of managed interfaces and throughput needs. Ask for the license basis, support terms, and whether the quote includes hardware or only software.
Rule design and engineering time	One-time to build the baseline ruleset and documentation, then recurring for changes. Paid to internal staff or an implementation partner.	Legacy flows nobody has documented and cloud sprawl with many subnets. Ask for a fixed-scope deliverable covering a rule inventory, the documented rationale for each allow rule, and a deny-all default.
Exception review and approval	Recurring. Paid as internal staff time from security, network and the business owner of each flow.	Number of standing exceptions and how often business systems change. Ask how exceptions expire, who approves them, and how each one is recorded in the system security plan.
Log storage and review	Recurring. Paid for storage capacity, SIEM or log platform licenses, and analyst time.	Volume of denied and allowed events and retention periods. Ask which events are logged, where they are stored, and how reviews are evidenced.
Configuration assessment and monitoring	Recurring. Paid for scanner or monitoring tooling and staff time to act on findings. Open-source tools such as Wazuh and Fleet can reduce tooling spend.	Number of endpoints and policies checked. Ask how the tool shows drift from the approved boundary configuration and who receives alerts.
External testing or independent review	Periodic. Paid to a qualified security testing firm or reviewer, separate from the assessor.	Scope of the boundary, number of external services and whether testing includes firewall rule review. Ask for a written scope and deliverables before work starts.
Assessor time	Periodic. Paid to the assessing body for the assessment engagement.	Evidence readiness and the number of interfaces the assessor must examine. Ask the assessor for the evidence list in advance so preparation is targeted.
Plan of action and milestones (if used)	Recurring until closed. Staff time to track and remediate the open item.	Under 32 CFR 170.24, 3.13.6 is scored at 5 points, and under 32 CFR 170.21 it cannot be placed on a POA&M for Conditional status. Plan to finish this requirement before the assessment, because the cost of a gap is higher for this control.

Open-source tools that support 03.13.06 evidence

Four open-source tools can produce parts of the evidence an assessor reviews for 03.13.06. Each covers a different layer: the network boundary, the web application edge, and the configuration of endpoints. None of them proves on its own that traffic is denied by default, so the organization still needs its own rule sets, documentation and test results.

OPNsense firewall rules

OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. A default-deny rule at the end of the ruleset, with explicit pass rules above it, is the configuration an assessor expects to see for 03.13.06. Aliases group address ranges so the allowed list is readable and reviewable. Enable per-rule logging so each match is recorded, then confirm with your assessor that the exported rule set and log samples meet the evidence they want. The license is BSD-2-Clause.

Coraza web application firewall

Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects HTTP traffic for attacks such as SQL injection, cross-site scripting and code injection, which is a narrower job than controlling which network flows are permitted. It integrates with Caddy, HAProxy, Traefik and Nginx, so it can sit at the managed interface in front of published services. The license is Apache-2.0. Confirm with your assessor whether HTTP inspection counts as evidence for your boundary design.

Wazuh configuration assessment

Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. Most policies are based on CIS benchmarks, and custom policies can be added. The checks cover files, directories, registry keys and running processes, and the results include remediation advice. This evidence shows that host firewall and service settings match the approved baseline. It does not check network rules on the boundary device, so pair it with firewall exports. The license is GPL-2.0-only.

Fleet policies for endpoint checks

Fleet policies ask yes or no questions of devices as osquery queries, and the policies page shows which devices on each fleet pass or fail each policy. Use them to confirm that endpoints hold the host-level network settings your design relies on, such as an enabled host firewall. The policy results give a dated pass or fail view per device that you can export for the assessment file. Fleet does not inspect network traffic or boundary rules. The license is MIT.

Who owns deny by default and who can help

Your organization owns the requirement. That means the boundary protection policy, the decision that all traffic is denied unless a documented need allows it, and the approval for every exception. Assessors will ask who signed off on each permitted flow and whether the approval was made by someone accountable for the CUI environment, not by the engineer who configured the rule.

Policy and procedures: Write the rule that network communications are denied by default and allowed only by exception, and assign who maintains it.
Exception approvals: Record who approved each permitted flow, the business reason, the owner, and the review date.
System security plan entries: Describe how the boundary is implemented, which managed interfaces exist, and how they are monitored, so the plan matches the running environment.
Periodic review: Confirm that unused exceptions are removed and that changes go through your change control process.
Staff responsibilities: Name the people with boundary protection duties, since assessors interview them.

Ask your team to confirm that the policy, exception register and system security plan entries exist and agree with each other before any outside party is engaged.

Where 03.13.06 implementations usually fall short

Deny-by-default looks simple on paper, but most failures come from rules that outlived their purpose, traffic that escapes the boundary inventory, and assumptions nobody tested. The cards below cover the gaps assessors most often find when they test the mechanisms behind 03.13.06, each with a closing action the organization can take before the assessment.

Permissive any-to-any rules from migration

A rule that allows any source to reach any destination on any port often survives a migration because it was added to restore service quickly. It silently defeats the default deny that 03.13.06 expects. Review the rule base for sources or destinations set to any, and confirm that each remaining allow rule names a specific business purpose. Remove or narrow any rule that cannot be justified in writing.

Exceptions without owners or expiry

Exceptions are added for vendors, temporary projects and troubleshooting, then remain in place for years. Without a named owner and an end date, nobody can say why a path is open. Assessors who sample exceptions often find entries with no ticket reference. Require every exception to record its owner, business justification, approval and a review or expiry date, and remove exceptions that lack them.

Cloud security groups outside the boundary inventory

Security groups, network access control lists and cloud firewall policies often sit outside the inventory that the organization reviews as its boundary. Traffic permitted there may bypass the controls the assessor tests. Build one inventory that covers on-premises firewalls, cloud network policies and managed interfaces, and confirm that each one has a documented default deny stance. Ask the cloud team to export current policies so the inventory matches what is running.

No logging of rule matches

If allowed and denied traffic is not logged, the organization cannot show that the default deny is working or investigate unexpected flows. Check whether each rule can log its matches and whether those logs reach a central store where they are retained and reviewed. For 03.13.06, the examine method looks at system audit records, so logs should be available for the period under assessment. Enable logging on the default deny rule and on each exception, then sample the logs to confirm entries appear.

Untested assumptions about management networks

Teams often assume that management, backup and out-of-band networks are isolated from user and CUI segments, but the assumption is rarely tested. A single routed path, a shared jump host or a flat VLAN can connect them. Interview the people who run these networks, review the design documentation, and attempt to reach management interfaces from a CUI segment. Record the result, then fix any path that the design did not intend.

Rule sets that no one reviews

Firewall rule sets change through emergency changes and vendor requests, yet few organizations schedule a periodic review of every rule. Over time, rules accumulate, duplicates appear and the rule order changes what traffic is allowed. Assign a named reviewer, set a review cadence in the system security plan, and compare each review against change tickets. Keep the review record as evidence that the rule set is actively managed, not only configured once.

Why default deny is harder to prove than to configure

A firewall rule set can look correct on paper and still fail an assessment, because the assessor needs evidence that traffic not on the allow list is actually blocked and that every exception has a documented reason. For 03.13.06, the question is not only whether a default deny rule exists at each managed interface but whether the live configuration, the design documentation and the observed traffic all tell the same story. Start by exporting the effective rule set from each boundary device, such as an OPNsense firewall, and comparing it with the approved design. Confirm that the final rule is a deny for all traffic, and that every allow rule names a source, destination, port and protocol that someone can justify.

Tests and logs close the gap between configuration and behavior. A test should attempt traffic that is not permitted from each zone and record that it is blocked, and it should attempt the permitted flows to show they still work. OPNsense can log each rule match to its live log view, so enable logging on the default deny rule and on exceptions, then retain those records under your audit log policy. Confirm with your logging platform how long blocked-traffic records are kept and whether they are searchable by rule, because an assessor will often ask you to pull a sample of denied and allowed events for a stated period.

The examine and interview methods in SP 800-171A Rev. 3 matter because the paper trail and the people behind it are part of the proof. Expect to show the boundary protection procedures, the system design documentation and the configuration settings, then answer questions from the personnel who manage the boundary and the developers who built the segments. Each exception should have a named owner, an approval record and a review date, so you can explain why a port is open and who decided it. Ask your team now who owns each allow rule and where its change history lives, since an answer that depends on memory tends to fail the interview.

Questions buyers ask about the 03.13.06 cost and effort

How much effort does default deny usually take to implement?

The effort depends less on the rule language than on how many interfaces, flows and owners the organization has to account for. Default deny means every boundary policy starts from block, then each permitted flow needs a documented reason, an owner and a rule. Teams that already keep an accurate network diagram and interface list usually spend their time reviewing existing traffic. Teams without one spend most of their time discovering what the network actually carries. No researched figure is available for hours or cost, so ask a prospective partner to size the work from your own interface count, number of enclaves and change process before you accept any estimate.

What drives the cost of default deny up or down?

Most of the cost comes from a few variables you can measure before you engage anyone:

The number of managed interfaces, including cloud VPC edges, VPNs, remote access gateways and links to third parties
How many flows are undocumented, shared across systems or dependent on legacy services
Whether the CUI enclave is isolated already or sits inside a flat network
How many people can approve a rule change, and how formal that approval is

Each of these raises effort in a predictable way. Ask for the quote to break out discovery, rule design, testing and evidence collection separately so you can see which items shrink as your inventory improves.

Can we implement default deny in-house without outside help?

Yes, an organization can implement default deny with its own staff, since the organization owns its controls and the requirement does not require a particular vendor. The work is firewall policy design, change control and evidence capture, which many network teams already perform. Outside help is most useful when the team lacks time, has no current interface inventory, or needs an independent review before an assessment. An implementation partner prepares rules, configuration and evidence, but it does not issue assessment results. Confirm internally whether your team can staff discovery and change review at the same time as day-to-day operations.

What does the team need to provide before the work starts?

A default deny project depends on three inputs that the organization must supply:

An interface inventory listing every managed boundary, its purpose and its owner
Named change owners who can approve, reject and review each permitted flow
Read access to firewall and system logs so that rule matches can be reviewed

If any of these are missing, the first phase of work becomes discovery. Ask the partner to state in writing which of these inputs it expects you to provide and which it will create.

How long does default deny take, and how does scope change it?

The duration depends on scope, and no researched timeline applies to this requirement, so treat any figure you hear as unverified until it is tied to a written scope. Duration grows with the number of enclaves, the number of interfaces and the state of your documentation. A single, well-documented enclave is a much smaller job than a multi-site environment with unknown flows. Ask the partner to show the phases, what each phase depends on, and which milestones your team must sign off on.

What will an assessor ask to see for 03.13.06?

An assessor will test whether the system denies network traffic by default and permits only specifically authorized traffic. Expect requests for the boundary protection procedures, system design documentation, current configuration settings for each managed interface, and audit records that show rule matches and changes. Assessors also interview the people who manage boundary protection and the system developers. Gather a rule-by-rule register with business justification, owner and review date before the assessment, because those records are the fastest way to show intent. Confirm the exact evidence expectations with your assessor, since the assessment method is theirs to apply.

Can 03.13.06 go on a POA&M, and when is that allowed?

Whether 03.13.06 can appear on a plan of action and milestones depends on the contract framework that applies to you. Under CMMC Level 2, 32 CFR 170.21 does not allow this requirement on a POA&M for Conditional status, and the requirement carries 5 points under the 32 CFR 170.24 scoring methodology. Check which framework your contract cites before you plan around a POA&M, because the rules differ. Confirm the current status with your contracting officer and assessor rather than assuming the rule carries across contracts.

What should we ask for in a partner quote for default deny?

A useful quote separates the scope into deliverables you can check: interface discovery, a current rule register, rule redesign, test evidence, log review procedures, and handover to your operations team. Ask which items are one-time and which recur, such as periodic rule reviews. Ask who is paid for each item, whether the partner or your staff holds the firewall changes, and what happens if discovery finds more flows than expected. Request written assumptions about enclave count, interface count and your inputs, and ask how any change to scope is priced. DeployOpen does not publish a price list and provides a quote from a written, fixed scope.

How DeployOpen scopes and prepares 03.13.06 evidence

DeployOpen approaches 03.13.06 as a boundary design and evidence task: the organization owns the requirement, we prepare the deny-by-default rule set, its configuration and the records an assessor will examine. Only an independent assessor can issue an assessment result.

How we scope

Inventory every network boundary, managed interface and allowed flow that carries CUI in the organization's own environment.
Agree in writing which systems, cloud accounts and sites fall inside the 03.13.06 scope before work starts.
Confirm with the organization which traffic is permitted by exception and who approves each exception.

How we build

Configure a default-deny policy on the firewall at each managed interface, with explicit allow rules tied to documented business purposes.
Group addresses and ports into aliases so each permitted flow is reviewable by source, destination, port and protocol.
Enable rule-match logging on the boundary and test that blocked traffic is denied and logged as designed.

How we hand over

Deliver the rule set, configuration exports and a map linking each allow rule to its exception record and owner.
Provide the system design documentation and boundary procedures an assessor will examine for the two determination statements.
Document test results showing deny-by-default behavior, so the organization can walk an assessor through the evidence.

How we support

Fixed-scope engagements end with written handover, and ongoing support is available as a retainer.
Review exception requests and rule changes against the documented baseline during a retainer, where the organization asks for it.
Confirm with the organization's assessor which evidence format and sampling they expect before final handover.