The implicit deny is the rule nobody writes: at the end of every access control list there is an invisible entry that drops anything the list did not explicitly allow. It is not a quirk and not a safety net added afterward.
RFC 4949 defines an access control list as a mechanism that works by enumerating the entities that are permitted, so anything not enumerated is not permitted by definition. What causes trouble is almost never the implicit deny itself.
It is that lists are read top to bottom and stop at the first match, so a permit sitting below a broader rule is never reached, and a list applied where the traffic does not pass never runs at all.
- Every access control list ends in a deny that is not written down
- It exists because a list enumerates what is permitted, per RFC 4949
- Rules are read top to bottom, stopping at the first match
- A permit below a broader rule is dead, and looks like a blocked port
- Removing the list to test it removes the implicit deny too
On this page
What it isThe rule that is not written down
Start from what access control lists are, because the behavior follows from the definition rather than being a design choice somebody made.
RFC 4949 defines an access control list as a mechanism that implements access control for a system resource by enumerating the entities that are permitted to access it. Read that carefully. The list names what may pass. It does not name what may not, because that set is everything else and nobody can write it down.
So the implicit deny is not an extra rule at the bottom of the ACL. It is what the list means. A list of five permit rules is a statement that those five things are allowed, and the only consistent reading of that statement is that the sixth thing is not.
This is why an access list containing nothing but allow rules still blocks network traffic, which surprises people the first time. Cisco calls them permit rules, most firewalls call them allow rules, and the default behind them is the same.
Adding a list that allows web traffic on ports 80 and 443 does not add a permission to a network that allowed everything. It replaces allowing everything with allowing those ports, and the change nobody notices is the second half.
Rule orderFirst match wins, and that is the whole story
The second half of the behavior is the firewall rule order, the sequence the rules are evaluated in, and it causes far more outages than the implicit deny does.
An ACL is read from the top. The first entry that matches the packet decides its fate, the action is taken, and nothing below that entry is considered. There is no scoring, no most-specific-wins and no second opinion among the rules. It is the first match, and then the list is finished.
| Order | Rule | What it does to a packet from 10.0.5.9 |
|---|---|---|
| 1 | permit 10.0.0.0/8 to the file server | Matches, permitted, list ends here |
| 2 | deny 10.0.5.0/24 to the file server | Never evaluated |
| 3 | permit anything to the web proxy | Never evaluated |
| 4 | the implicit deny | Never reached |
The second entry in that list is doing nothing at all, and reading the configuration does not reveal it. Everything is spelled correctly, the addresses are right and the intent is obvious to a human. The device is simply never getting that far.
The mirror image is the more common one in practice: a specific permit placed below a broader deny. It never runs, the network traffic is dropped, and the symptom is indistinguishable from a firewall that has no rule for it at all.
DiagnosisWhy the rule you just added did nothing
This is the situation that brings people to this subject, and there are only a few explanations. Work through them in this order before touching the firewall again.
Something above it already matched. The ACL stopped before reaching your line. Look upward from your rule rather than at it, which is where people spend the time.
The ACL is not applied where the traffic goes. A list attached to the wrong interface, or the wrong direction on the right interface, never sees the packet. It is correct and irrelevant at the same time.
The traffic does not match what you wrote. The wrong protocol, one of the ports you assumed rather than checked, a source address being translated before it reaches the rule. A rule matching an address the packet no longer has will never fire.
The change was not committed or the session is cached. Some platforms need an explicit apply, and an existing connection already permitted by a state table keeps flowing regardless of what the rules now say.
The return traffic is what is blocked. Covered below, and it is the one that looks most like a mystery.
Return trafficReturn traffic, which is where it bites
RFC 4949 puts the difficulty plainly in its own tutorial on firewalls: the hard part is defining the criteria by which packets are denied, because a firewall has to keep unauthorized traffic out while still letting authorized traffic pass in both directions.
Both directions is the phrase that matters. A request goes out and an answer comes back, and the answer is a separate packet arriving from outside with the source and destination reversed.
On a stateful firewall this is handled for you. Stateful firewalls remember the outbound connection and allow the reply because it belongs to a session already approved. No extra rule is written.
On a stateless filter, which is what a router ACL usually is, nothing is remembered. A list of rules that allows outbound traffic and says nothing about inbound allows the request and drops every reply, and the implicit deny is what drops them. The rule looks correct because it describes the direction somebody was thinking about.
The symptom is characteristic and worth memorizing: the connection is not refused, it hangs. A refusal is an answer. Silence is a packet meeting a deny that does not send anything back.
Everywhere elseThe same default, everywhere a list decides access
This is usually taught as a router and firewall topic, which makes it look like a packet filtering quirk. It is not. All access control lists work the same way, because ACLs everywhere do the thing RFC 4949 describes: enumerating what is permitted.
| Where you meet a list | What the list holds | What the implicit deny looks like |
|---|---|---|
| A router or switch ACL | Permit and deny entries by address, protocol and port | Packets vanish, and the connection hangs |
| A firewall policy | Rules by zone, source, service | Traffic dropped, usually with a log if you asked for one |
| A cloud security group | What is allowed to reach and leave a resource | Anything not allowed simply never arrives |
| A file system ACL | Which accounts may read or write an object | No entry for you means no access to the object |
| Application authorization | Which roles may call which endpoint | A 403, which at least tells you it was refused |
The bottom row is the outlier and it is worth noticing. An application usually answers when it refuses you. The network layers usually do not, and that silence is the reason a packet filter is harder to debug than a permissions error on a file.
The security value is the same in every row, on network devices and on other systems alike, and it is a filtering principle rather than a networking one.
A list that fails closed denies something it should have allowed, which produces a support ticket. One that fails open allows something it should have denied, which produces no ticket at all until much later. Defaulting to deny is the choice to be told about your mistakes.
Why it mattersWhy implicit deny is the default in network security
An implicit deny rule is the network form of least privilege. Network administrators cannot list everything that should be blocked. So they list the specific traffic the business needs, and the firewall denies the rest by default. That stance is also called default deny.
Three network security benefits follow from it, and each one lowers risk without anybody writing a block rule.
- A smaller attack surface. Only the ports and protocols somebody explicitly allowed can be reached through the firewall. A service installed later and never added to the firewall rules stays blocked.
- Unknown traffic is denied too. A default deny does not need to recognize a new threat in order to block it. Anything the rules do not allow is dropped, including unauthorized traffic nobody predicted.
- Mistakes get reported. An application that stops working produces a complaint. A port left open that should have been closed produces nothing.
The same principle sits under zero trust: no network traffic is trusted because of where it comes from, and access is allowed only by explicit policy.
It also applies in both directions. Many small business firewalls are set up to deny inbound traffic by default and allow any outbound traffic.
Extending the implicit deny to outbound rules, so only the specific traffic the network needs is allowed out, limits what malware on an infected machine can reach. Outbound filtering is as much a part of network security as inbound filtering.
Explicit deny rules and the implicit deny together
An explicit deny is a rule somebody wrote to block specific traffic: one address, one range, one protocol such as Telnet. It belongs above the allow rules it is meant to override, because the first match wins. The implicit deny catches whatever is left at the bottom.
A sound firewall rule order is specific explicit deny rules first, then specific allow rules, then broader allow rules, then the implicit deny. On Cisco style ACLs the written form of that last line is deny ip any any, often with the log keyword:
permit tcp any host 203.0.113.10 eq 443
permit tcp any host 203.0.113.10 eq 80
deny ip any any logThe last line changes nothing about what the ACL allows. In a Cisco ACL implicit deny never appears in the configuration, and this line makes it visible, with a hit counter and a log entry for every packet denied.
PitfallsWhere people go wrong
Blaming the implicit deny. It is the default and it is the correct network security posture. The fault is almost always rule order, placement, or a direction nobody wrote a rule for.
Testing by removing the list. Taking the list off removes the implicit deny along with everything else, so traffic flows and you have learned nothing about which line was responsible.
Adding a permit any at the bottom. It goes below the rules that already block the traffic, so it changes nothing for that traffic, and it destroys the fail-safe default by letting everything else through the firewall.
Forgetting the return direction. A stateless filter needs both directions described. Permitting the request and stopping there produces a hang rather than a refusal.
Assuming the most specific rule wins. It does not. First match wins, so a broad rule at the top overrides every precise rule underneath it in the ACL.
Never logging the deny. An explicit deny rule at the end of the ACL costs nothing in behavior and is the difference between a diagnosis and a guess.
ComparisonAn implicit deny, an explicit deny and a permit at the end, side by side
| Criterion | Implicit deny | An explicit deny at the end | A permit at the end |
|---|---|---|---|
| Blocks unmatched traffic | Yes | Yes | No |
| Appears in the configuration | No | Yes | Yes |
| Can be logged | Rarely | Yes | Not applicable |
| Shows a hit counter | No | Yes | Yes |
| Tells you it is doing something | No | Yes | No |
| Fails safe | Yes | Yes | No |
The row that decides this argument is the fourth. An explicit deny rule at the end of an access list does exactly what the implicit one already does, and it does it visibly, with a counter that increments and a log line you can read.
Adding it changes no behavior and turns an invisible drop into evidence. That is the single most useful thing on this page. If traffic is disappearing and you cannot prove where, write the deny down.
FAQFrequently asked questions
What is implicit deny?
An unwritten rule at the end of every access control list that drops anything the list did not explicitly allow. It is not configured; it is what the ACL means.
Why does implicit deny exist?
Because a list enumerates what is permitted. RFC 4949 defines an access control list for a system resource that way, so anything not enumerated is not permitted, and no separate rule is needed to say so.
Does an ACL with only permits block anything?
Yes, everything else. That is the part people miss: applying such an ACL does not add a permission, it replaces allowing everything with allowing only the network traffic listed.
In what order are firewall rules evaluated?
Top to bottom, stopping at the first match. The action of the matching rule is taken and nothing below it in the list is considered.
Why did my new rule do nothing?
Usually because something above it matched first. Check upward from your rule, then check that the list is applied to the right interface and direction.
Does the most specific rule win?
No. The first matching rule wins regardless of how specific it is, which is why a broad permit at the top of a list disables everything precise below it.
Why does my connection hang instead of being refused?
Because a deny that silently drops the packet sends nothing back. A refusal is an answer; silence usually means an implicit deny somewhere in the path.
Is implicit deny logged?
Usually not. That is the main argument for adding an explicit deny as the last entry, which behaves identically and produces a counter and a log line.
What is the difference between implicit deny and default deny?
They describe the same security principle. Implicit deny is the name for it inside a specific access list; default deny usually describes the posture of a whole policy.
Do I need a rule for return traffic?
On a stateless filter, yes. Stateful firewalls track the outbound connection and allow the reply automatically, which is one of the main reasons to have one.
Should I add an explicit deny at the end?
It is worth it. Behavior does not change, and you gain a hit counter and the ability to log what is being dropped, which turns an invisible failure into a visible one.
Is implicit deny the same as a blocked port?
From the outside they look identical, which is exactly the difficulty. Both produce silence, and telling them apart means reading the ACL rather than testing from the client again.
Is a deny all rule the same as implicit deny?
They do the same job. Implicit deny is the unwritten rule at the end of an access list that drops anything not permitted above it. A deny all rule is the same thing written out, usually so that dropped traffic can be logged. Both follow the principle that traffic is blocked unless something allows it.
How does an ACL work on a firewall or a network device?
An ACL on a firewall or network device is an ordered list of permit and deny statements matched from the top down. The first match wins and the rest are ignored, which is why order matters more than content. On a router a network ACL filters by address and port, while a firewall also tracks connection state.
Keep readingRelated concepts
Read next · Network security What Is a Firewall? The state table that permits return traffic automatically, which is the difference between a hang and a working connection. Open this next14 min- Network security · 12 min IDS vs IPS What sits alongside the rules and inspects what they let through, since a permit is not an opinion about the contents.
- Network security · 9 min Cyber Security vs Network Security, and What the Firewall Does Not Cover Where rule-based filtering sits in the wider set of controls, and the four starting points it does not stand in front of.
- Ports · 8 min Port 4444, and Why an Abandoned Port Makes a Clean Signal A number worth blocking, and why blocking it is not the control.
- Network security · 10 min Stateful vs Stateless Firewall, and Where Stateless Filtering Still Lives Stateful and stateless rules compared, including why a stateless ACL needs a rule for replies.