What is a perimeter firewall and what can it not protect?

A perimeter firewall is a device or service at the boundary between your network and an untrusted one, usually the internet. It allows or blocks traffic against a rule set. It is a sound first control, but it only sees traffic that crosses the boundary, so it cannot stop movement inside the network.

What does it do?

NIST SP 800-41 Rev. 1 defines firewalls as devices or programs that control the flow of network traffic between networks or hosts with different security postures. The perimeter version sits where an internal network meets an external one.

A well-run one does three jobs. It limits inbound connections to the few services you mean to publish. It limits outbound connections, which is the control most often skipped. And it logs what it allowed and denied, which gives incident responders a record.

How have firewalls changed?

NIST describes several technology types, from simple packet filters that check addresses and ports, to stateful inspection that tracks connections, to application-aware gateways that understand protocols. Each step adds visibility and cost. A filter that only checks ports cannot tell a web request from a tunnel running over port 443.

Modern perimeters also deal with encrypted traffic. Without decryption, a firewall sees the destination, not the content. Decryption brings its own risk, because the inspecting device then holds plaintext.

What are the limits?

The perimeter model assumes that inside is safer than outside. That assumption fails in at least four ways.

1. Users and devices leave the building. Remote work and cloud apps mean much traffic never crosses the office firewall.
2. Anything that gets in can move. A phished laptop is already inside. Flat internal networks let it roam.
3. Allowed traffic is the attack path. Email, web and VPN sessions are all permitted, so attacks use them.
4. The firewall itself is a target. Internet-facing network devices have a record of vulnerabilities, so keep them patched. CISA's Known Exploited Vulnerabilities catalog is a place to check whether your product has entries.

NIST SP 800-207 on zero trust frames this directly: network location alone should not grant trust. A perimeter firewall remains useful as one layer, not as the whole design.

A constructed example

A small firm allows outbound traffic to anywhere, since "it's only outbound." A single infected workstation then connects to its operator without any friction. Adding a rule that restricts outbound traffic to known ports and uses DNS filtering cuts that path, and the log of denied connections shows which workstation tried. The inbound rules were fine. The gap was outbound.

Where does it still earn its place?

Cutting the noise. A perimeter firewall removes a large amount of unwanted traffic before it reaches any server, restricts which services are reachable from outside, and gives you one place to apply emergency blocks during an incident. Those jobs do not go away with zero trust. They become one layer among several.

How to check or apply this

1. Export the rule set and mark each rule with an owner and a purpose. Remove rules nobody can explain.
2. Make the last rule deny all, then review anything permitting any source to any destination.
3. Add outbound filtering, at minimum for known-bad destinations and unneeded ports.
4. Restrict the firewall's management interface to an administrative network and require MFA.
5. Subscribe to vendor advisories and check the KEV catalog for your device, then patch on a fixed timeline.
6. Send firewall logs to central storage and alert on denied outbound spikes.
7. Segment the inside as well, so a single compromised host cannot reach everything.

Quick check

Sources

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• NIST SP 800-207, Zero Trust Architecture
• CISA Known Exploited Vulnerabilities Catalog

Last reviewed: 18 October 2026.