Hardware firewalls are no longer the center of the security universe, but they still matter when they enforce segmentation, preserve resilience, and feed the telemetry that zero trust decisions depend on.

Zero trust did not make hardware firewalls obsolete. It made perimeter-only thinking obsolete. NIST defines zero trust as a shift from static, network-based perimeters toward protection focused on users, assets, and resources, with no implicit trust granted solely because a user or device is on a particular network (NIST SP 800-207). That definition does not say “remove firewalls.” It says the firewall can no longer be the single control that decides whether something is trusted.

The better question is not whether hardware firewalls are still relevant. The better question is where they still provide defensible value in an architecture that assumes breach, verifies continuously, and applies policy as close as possible to the resource.

The short answer

Hardware firewalls remain relevant in zero trust environments when they perform three jobs well:

Constrain blast radius: Enforce macro-segmentation between business zones, data sensitivity tiers, operational technology, management planes, user networks, and internet-facing services.
Provide durable enforcement: Maintain deterministic controls at physical chokepoints where cloud-native, endpoint, or identity-based enforcement may not exist, may not be mature, or may not be trusted alone.
Generate high-value telemetry: Contribute network flow, session, application, policy, and denial events into the visibility and analytics layer that zero trust programs need to detect abnormal behavior.

They become less relevant when organizations use them as a substitute for identity-aware access, workload-level policy, device posture, continuous monitoring, and least-privilege authorization. In that model, the firewall becomes a very expensive moat around a castle whose occupants are already assumed to be compromised.

Why the perimeter lost its monopoly

The legacy firewall model was built around a practical assumption: trusted users and systems were mostly inside the enterprise network, while untrusted traffic came from outside. That assumption no longer maps cleanly to how enterprises operate. NIST explicitly ties zero trust adoption to enterprise trends such as remote users, bring-your-own-device patterns, and cloud-based assets outside an enterprise-owned network boundary (NIST SP 800-207).

This is why zero trust changes the firewall conversation. If applications live in multiple clouds, users connect from unmanaged networks, and sensitive data moves through SaaS platforms, the hardware firewall at headquarters can no longer be the primary trust broker. It may still inspect traffic crossing a data center edge, but it does not see every resource request, every SaaS session, every service-to-service call, or every identity signal.

CISA’s Zero Trust Maturity Model reinforces this architectural shift by presenting zero trust as a maturity journey across pillars rather than a single network appliance purchase (CISA Zero Trust Maturity Model). The implication is simple: a firewall can participate in zero trust, but it cannot be zero trust.

What zero trust still needs from the network

The strongest argument for keeping hardware firewalls is not nostalgia. It is segmentation.

The NSA describes the zero trust network and environment pillar as a way to curtail adversary lateral movement by logically and physically segmenting, isolating, and controlling access across on-premises and off-premises environments (NSA Zero Trust Network and Environment Pillar). That is exactly where hardware firewalls can still earn their place, particularly in hybrid environments where physical data centers, cloud connections, privileged management networks, and operational technology need hard boundaries.

NSA guidance on network infrastructure also recommends strict perimeter access controls, deny-by-default rulesets, and multiple layers of firewalls throughout a network to restrict inbound traffic, restrict outbound traffic, and examine internal activity between network regions (NSA Network Infrastructure Security Guide). That recommendation is not in conflict with zero trust. It is a reminder that zero trust still depends on enforceable control points.

The mistake is treating those control points as proof of trust. A packet permitted through a firewall is not necessarily safe. A subnet location is not an identity. A source IP is not a business role. A VLAN is not authorization. Firewalls can reduce paths, but zero trust requires deciding whether a specific subject, device, workload, and context should access a specific resource at a specific time.

Where hardware firewalls still make sense

Data center and hybrid-cloud boundaries

Many enterprises still run identity systems, file services, databases, management tools, backup platforms, and regulated workloads in data centers or colocation facilities. Hardware firewalls remain useful at the boundary between those environments and external networks, private WANs, cloud on-ramps, partner connections, and internet ingress or egress paths.

In a zero trust architecture, the firewall at this layer should not grant broad internal trust. It should enforce explicit traffic contracts: which source zones may reach which destination zones, on which ports and protocols, for which business purpose, with logging enabled and a default-deny posture.

Segmentation for regulated and high-impact systems

Hardware firewalls are still compelling where segmentation has audit, safety, or mission implications. Examples include controlled unclassified information environments, payment systems, healthcare workloads, backup vaults, privileged access management infrastructure, domain controllers, security tooling, and operational technology.

The MITRE ATT&CK mitigation for network segmentation describes using architectural sections to isolate critical systems, functions, or resources as a way to limit adversary movement (MITRE ATT&CK M1030). Hardware firewalls are not the only way to implement that mitigation, but they remain a familiar and inspectable way to enforce it across network zones.

Operational technology and appliance-heavy environments

Zero trust discussions often assume modern endpoints, cloud-native workloads, APIs, and identity-aware applications. Operational technology environments do not always look like that. Industrial systems, building management platforms, medical devices, lab equipment, and embedded appliances may have limited support for modern agents, strong identity, or rapid patching.

In these environments, hardware firewalls can provide compensating controls around fragile systems. They can restrict management protocols, isolate vendor access, separate safety-critical systems from general IT networks, and create inspection points where endpoint-based controls are unavailable or inappropriate.

Resilience during identity or endpoint control failure

Zero trust programs rely heavily on identity providers, endpoint posture systems, policy engines, device inventories, and telemetry pipelines. Those dependencies improve security when they work, but they also become critical infrastructure.

Hardware firewalls can provide a fallback enforcement layer when an identity integration fails, an endpoint agent breaks, a cloud policy misconfiguration propagates, or a SaaS control plane becomes unavailable. They should not be the only control, but they can be a stable guardrail when higher-order controls degrade.

Where hardware firewalls are the wrong answer

Hardware firewalls are poorly suited to solve problems that now live above the network layer.

They cannot reliably determine whether a user session is backed by phishing-resistant multifactor authentication. They cannot evaluate whether a device is compliant with current endpoint policy. They cannot understand whether a service account request is expected behavior for a workload. They cannot classify SaaS data access without additional integrations. They cannot see every east-west flow in cloud-native environments unless the architecture deliberately routes that traffic through them, which can introduce cost, latency, and fragility.

This is why “just backhaul it through the firewall” is often the wrong modernization strategy. It may restore a familiar inspection model, but it can also create hairpin traffic patterns, brittle routing dependencies, and blind spots in identity context. Zero trust asks teams to place policy enforcement where it has the best context, not where the network diagram is most comfortable.

The zero trust test for any firewall investment

Security leaders should evaluate hardware firewall investments against five zero trust questions:

What resource is being protected? If the answer is “the network,” the design is probably too broad. If the answer is a specific application tier, management plane, data enclave, or partner path, the firewall has a clearer purpose.
What trust decision is the firewall actually making? A firewall rule based only on IP address and port may be necessary, but it is rarely sufficient for modern authorization.
What telemetry does it produce? Firewall logs should feed centralized detection, investigation, compliance reporting, and policy tuning workflows rather than sitting in a device console.
How does policy stay current? Manual rule review does not scale in dynamic environments. Firewall policy should be tied to asset inventory, data flow mapping, change management, and periodic recertification.
What happens if it fails? High availability, bypass risk, management-plane security, backup configuration, and recovery procedures matter because firewall outages can become business outages.

If a proposed firewall purchase cannot answer those questions, it may be a perimeter refresh wearing a zero trust label.

A practical architecture pattern

A defensible hybrid zero trust architecture usually treats hardware firewalls as one enforcement layer among several:

Identity layer: Centralize authentication, authorization, privileged access, and conditional access decisions.
Device layer: Measure device health, configuration, vulnerability exposure, and management state.
Network layer: Use hardware and virtual firewalls to enforce segmentation, egress control, partner access restrictions, and management-plane isolation.
Application and workload layer: Apply service-level policy, workload identity, API controls, and runtime protections close to the resource.
Data layer: Classify, label, encrypt, monitor, and govern access to sensitive data.
Visibility and analytics layer: Correlate firewall, endpoint, identity, cloud, SaaS, and application telemetry into detection and response workflows.

This pattern aligns with CISA’s treatment of zero trust as a multi-pillar maturity model and with NIST’s framing of zero trust as an architecture focused on resources rather than network segments alone (CISA Zero Trust Maturity Model, NIST SP 800-207).

In that architecture, a hardware firewall is not a trust engine. It is a policy enforcement point, a segmentation boundary, and a telemetry producer.

The decision framework

Keep or invest in hardware firewalls when:

You need enforceable segmentation between high-impact zones.
You operate data centers, colocation, operational technology, or appliance-heavy environments.
You require deterministic egress control for regulated systems.
You need inspection and logging at partner, WAN, cloud interconnect, or internet boundaries.
You can integrate firewall events into your broader detection and response pipeline.

Reduce reliance on hardware firewalls when:

The protected resources are primarily SaaS or cloud-native services.
Identity, device posture, and application context are more important than network location.
Backhauling traffic increases latency, cost, or architectural fragility.
Firewall rules have become a substitute for asset ownership, data classification, and least-privilege access.
Teams cannot explain which business flows each rule supports.

Retire or redesign firewall deployments when:

They exist mainly to preserve legacy network zones that no longer reflect business risk.
They create a false sense of compliance without improving detection or containment.
They block modernization toward workload-level, identity-aware, or cloud-native enforcement.
They are unmanaged, poorly logged, inconsistently patched, or excluded from resilience planning.

The bottom line

Hardware firewalls are still relevant in the zero trust world, but only after they lose their throne.

Zero trust shifts the center of gravity from the perimeter to the resource. That shift does not eliminate the need for network enforcement. It forces network enforcement to become more precise, better instrumented, and more honest about what it can and cannot decide.

For most enterprises, the right answer is not “replace every firewall with zero trust.” The right answer is to stop asking firewalls to make trust decisions they were never designed to make. Let identity, device posture, workload policy, and data controls decide access. Let firewalls do what they still do well: reduce unnecessary paths, separate high-impact environments, enforce explicit flows, and produce telemetry that helps defenders see what is happening.

The firewall is not dead. The firewall as the security strategy is.

Cyberuptive helps medium and large businesses, MSPs, and Pacific defense subcontractors design zero trust architectures that pair modern identity, device, and workload controls with the network enforcement points that still earn their keep.

Talk to us about a zero trust architecture review, or read our Managed Detection and Response overview.