Where does a virtual firewall fit in a zero trust design?

In a zero trust design, a virtual firewall acts as a policy enforcement point: it allows or blocks a connection based on a decision about who or what is asking, not because the traffic came from a trusted zone. It adds segmentation inside cloud and virtual networks, but it is one control in the design, not the design.

What does zero trust change about firewalls?

NIST SP 800-207 describes zero trust as moving defenses from static network perimeters to focus on users, assets and resources, and removing implicit trust based on network location. Its architecture has a policy decision point, made of a policy engine and administrator, that decides whether to grant access, and a policy enforcement point that opens or closes the connection.

A firewall can be that enforcement point. The difference from the classic model is where the allow decision comes from. In the old model, a rule says the web subnet may talk to the database subnet. In zero trust, the rule is also informed by who is calling, from what device state, and for what purpose.

Where does a virtual firewall help?

Inside virtual networks, east-west traffic between workloads never meets a physical appliance. A virtual firewall, a software instance or a host-level rule engine, puts an enforcement point next to the workload. That makes fine-grained segmentation possible, down to a single application or workload, and reduces the reach of anything that gets in.

NIST SP 800-207A goes a step further for cloud-native applications. It describes a zero trust model in which access control uses application and service identities in addition to network parameters such as IP addresses and subnets, since addresses change constantly in dynamic environments. That points to a limit: an IP-based firewall rule is a weak proxy for identity.

A constructed example

A payments service in a cloud network receives calls from an orders service. A classic rule allows the whole orders subnet to reach the payments port. A zero trust version allows only the orders workload, identified by a service credential, to call the specific payments API, and denies the same call from a build server in the same subnet. If an attacker lands on the build server, the network path exists but the policy denies it, and the attempt is logged.

What does it not do?

A virtual firewall does not decide who the user is, verify device health, or classify data. Those signals come from identity, endpoint and data systems that feed the policy decision. It does not help if rules are broader than needed: a rule that allows any internal address to reach any port is a perimeter model in a zero trust costume.

It also adds management cost. Rules must follow workloads as they move, so policy is best defined by labels and identity, not by addresses.

How do you introduce it step by step?

Begin by mapping flows for one application. Observe what talks to what, then write rules for exactly those flows, in monitor mode first. Move from address-based to label-based or identity-based rules. Add device and user signals for administrative paths first, since they carry the most risk. Expand application by application.

How to check or apply this

1. Pick one application and record its real network flows for two weeks.
2. Write allow rules for those flows only, and run them in log-only mode.
3. Review denied-would-have-been entries with the application owner and fix the rules.
4. Move rules from IP addresses to labels or workload identities.
5. Add identity and device conditions for administrative access paths.
6. Send enforcement logs to central storage and alert on denied attempts to sensitive systems.
7. Repeat for the next application, using the same process.

Quick check

Sources

• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy

Last reviewed: 18 October 2026.