What are the benefits of a firewall, and what does it miss?

A firewall controls the flow of traffic between networks or hosts that have different security postures. Its main benefit is a single enforcement point where you decide what may cross. It reduces exposed services and gives you logs. It does not inspect your code, your users or your dependencies.

What does a firewall actually do?

NIST SP 800-41 Revision 1 describes firewalls as devices or programs that control the flow of network traffic between networks or hosts employing differing security postures. That wording matters. A firewall is a boundary tool. It only helps where there is a boundary: internet to data center, office to production, one cloud network to another, or a laptop to whatever network it landed on.

The same publication walks through several technologies. A packet filter is the most basic feature: it permits or drops traffic based on header fields such as addresses and ports. Stateful inspection improves on that by tracking the state of connections and blocking packets that deviate from the expected state. Application firewalls add protocol analysis, which some vendors call deep packet inspection, and application proxy gateways terminate the connection and make a fresh one on the client's behalf.

What are the real benefits?

A smaller attack surface. If a database port is not reachable from the internet, nobody can try passwords against it from the internet.

A place to write policy once. Instead of trusting every host to configure itself, you express intent at the boundary: only the load balancer reaches the app tier, only the app tier reaches the database.

Logs of what was denied and allowed. A deny log is early evidence of scanning, misconfiguration and a service that suddenly started talking to something new.

Containment. Internal segmentation means one compromised host does not automatically see every other host.

Host-level control. The NIST guide also covers host-based firewalls, which carry the same idea down to individual machines, useful for laptops that leave the office.

What does a firewall miss?

A firewall judges connections, not intent. A permitted request on port 443 can still carry an injection payload, a stolen session token or a malicious package download. A vulnerable library inside an allowed application is invisible to a packet filter. Encrypted traffic limits what a boundary device can see unless it terminates the connection.

A constructed example: a team exposes a customer API through a firewall that allows only HTTPS to one address. That is correct policy. A month later an authenticated user finds an authorization flaw and reads other customers' records. Every packet was permitted. The control that would have helped lived in the application and its tests, not in the network.

So treat the firewall as one layer. Pair it with patching, identity controls, application testing and dependency review.

How to check or apply this

1. List every boundary you rely on and name the device or setting that enforces it.
2. Start from deny. Permit only the traffic you can name, with an owner and a reason for each rule.
3. Review rules on a schedule and remove ones nobody can explain. Rule sets rot faster than almost any other configuration.
4. Narrow ICMP deliberately. NIST's guidance includes denying incoming and outgoing ICMP except the types and codes the organization specifically permits.
5. Turn on logging for denied traffic and send it somewhere a person will look.
6. Test after every change from outside the boundary, not just from the console.
7. Cover the layers a firewall cannot: scan your code and dependencies and fix what is reachable.

On that last point, Safeguard scans dependencies and uses reachability analysis to show which vulnerable code your application can actually call, which is the part a network boundary never sees.

Quick check

Sources

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, fetched 18 October 2026.

Last reviewed: 18 October 2026.