A perimeter firewall sits at the boundary between your internal network and the internet, and filters traffic in and out by rule. It remains a useful first control. It is not enough alone, because remote work, cloud services and attackers already inside the network all bypass the edge.
What does a perimeter firewall do?
NIST SP 800-41 Rev. 1 defines firewalls as devices or programs controlling the flow of network traffic between networks or hosts employing differing security postures. The perimeter is the clearest case of differing postures: the untrusted internet on one side, your managed network on the other.
At the edge a firewall usually does four jobs. It blocks unsolicited inbound connections. It permits specific inbound services, such as a web server, through a controlled path. It restricts which outbound connections internal systems may make. And it records what it blocked and allowed.
How should you configure the edge?
Start with default deny. Allow only named services to named hosts, and drop everything else. Place anything that must be reachable from the internet in a separate zone, often called a demilitarised zone, so that a compromised web server does not sit on the same segment as internal databases. CISA's DarkSide advisory applies the same idea to IT and operational networks: define a demilitarised zone between them and filter traffic between zones.
Outbound rules matter more than most teams think. If workstations may connect to any address on any port, malware can reach its command server freely. The same advisory lists filtering ingress and egress traffic to known malicious addresses as a mitigation.
Where does the perimeter model break down?
NIST SP 800-207 notes that zero trust grew out of enterprise network trends including remote users, bring your own device and cloud assets that are not located within an enterprise-owned network boundary. A perimeter firewall cannot filter traffic that never crosses it. A laptop on home broadband talking to a SaaS app does not touch your edge.
Allowed traffic is the second gap. If port 443 is open for a web app, an attack that arrives as a normal request goes through. And encrypted traffic leaves a perimeter device with limited visibility unless it decrypts, a trade-off covered in RFC 8404.
The third gap is lateral movement. Once something is inside, a flat network lets it roam, because the edge firewall never sees internal traffic.
What does a constructed example show?
A company has a tidy edge: default deny inbound, one open port to a web server in a separate zone. A staff member clicks a phishing link and approves a sign-in prompt. The attacker uses the stolen session from a cloud service, never touching the perimeter. Later, a contractor's infected laptop joins the office wifi and scans internal servers. The edge firewall sees none of it.
The controls that matter here are multifactor authentication that resists approval fatigue, segmentation inside the network, host firewalls, and logging.
What should sit beside the perimeter?
- Internal segmentation, so one compromised host cannot reach everything.
- Host firewalls, which travel with the device.
- Identity based access to applications, in line with NIST's zero trust guidance.
- Monitoring of both blocked and allowed traffic.
- Patching of the services you expose through the edge.
How to check or apply this
- Export your edge rules and confirm the last one is a deny.
- List every inbound allow rule and name the owner and reason.
- Put internet-facing servers in a separate zone from internal systems.
- Review outbound rules and restrict what workstations and servers may reach.
- Test from outside with an authorised scan and compare with your design.
- Add one control beyond the edge this quarter, such as internal segmentation or per-application access.
Quick check
Is a perimeter firewall obsolete?
No. It remains a useful control at the network boundary. It is just not sufficient on its own for cloud, remote and internal threats.
What is the most common perimeter mistake?
Leaving old allow rules in place after the need is gone, and leaving outbound traffic unrestricted.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- NIST SP 800-207, Zero Trust Architecture
- CISA AA21-131A
- RFC 8404, Effects of Pervasive Encryption on Operators
Last reviewed: 18 October 2026.
