Let me start with something that might be unpopular.

Most Zero Trust implementations I’ve seen aren’t Zero Trust. They’re network segmentation with a rebrand. They’re VLANs with stricter ACLs and a slide deck that says “Zero Trust” on the cover.

That’s not a criticism of the engineers who built them. It’s a reflection of how the term has been marketed — as a product you buy rather than an architecture you build. Every vendor has a “Zero Trust solution” now. Most of them are useful tools. None of them, on their own, give you Zero Trust.

This post is about what Zero Trust actually looks like when you implement it on Palo Alto NGFW and Panorama — not the marketing version, the real one.

What Zero Trust Actually Means

The original concept comes from John Kindervag’s work at Forrester back in 2010. The core idea is simple: stop assuming that traffic inside your network is trustworthy just because it’s inside your network.

The traditional perimeter model says — build a strong wall, and everything inside is trusted. The problem with that model is that once someone gets through the wall (and they will), they can move laterally through your environment with very little friction. The perimeter is hard on the outside and soft in the middle.

Zero Trust says — trust nothing, verify everything. Every connection, every user, every device, every application request needs to be authenticated and authorised. Even if the request is coming from inside your network. Even if it came from the same subnet as your most trusted server.

Three principles underpin it:

Never trust, always verify. Every access request is authenticated regardless of where it originates.

Least privilege access. Users and systems get access to exactly what they need. Nothing more.

Assume breach. Design your network as if an attacker is already inside. Segment aggressively. Contain the blast radius.

Simple in principle. Genuinely hard to implement properly. Let’s talk about how Palo Alto makes it achievable.

Why Palo Alto is Well-Suited for Zero Trust

I’m not going to pretend this is a vendor-neutral post. I work with Palo Alto every day. It’s what I know best and it’s what most of my clients run.

That said — Palo Alto’s architecture genuinely lends itself to Zero Trust in a way that traditional stateful firewalls don’t.

The key is App-ID and User-ID. Traditional firewalls make decisions based on IP addresses and ports. Palo Alto makes decisions based on the actual application and the actual user. That distinction matters enormously for Zero Trust, because Zero Trust is fundamentally about who is doing what, not just where traffic is coming from.

When you combine App-ID, User-ID, Device-ID, and Panorama’s centralised policy management across multiple sites — you have the building blocks of a genuine Zero Trust architecture. You still have to build it. But the building blocks are there.

Pillar 1 — Never Trust, Always Verify

User-ID

The foundation of verification on Palo Alto is User-ID. Instead of writing security policies against IP addresses, you write them against users and groups from your directory — Active Directory, LDAP, whatever you’re using.

This matters because IP addresses lie. A user sitting at a workstation today might be at a different desk tomorrow. A server IP might get reassigned. Policies written against IPs need constant maintenance. Policies written against users and groups stay accurate as long as your directory stays accurate.

Setting up User-ID involves deploying the User-ID agent (or using the agentless option for smaller environments) and connecting it to your identity provider. The firewall then maps IP addresses to usernames in real time, and your security policies can reference those usernames directly.

One thing I always recommend — enable User-ID on a per-zone basis. Don’t enable it everywhere by default. Think about which zones actually benefit from user-based policy enforcement and enable it selectively.

MFA Enforcement

User-ID tells you who a user is. MFA tells you that they are who they claim to be.

Palo Alto’s GlobalProtect can enforce MFA at the VPN gateway level. But for internal resources, you can also use Authentication Policy to require MFA before granting access to sensitive applications — even for users who are already on the network.

This is one of those things that sounds obvious but is almost never implemented. Most organisations require MFA to get onto the VPN. Almost none require it again to access their most sensitive internal systems. If an attacker compromises a machine that’s already connected to the VPN, they inherit whatever access that machine had — without ever touching MFA.

Authentication Policy closes that gap. It’s one of the most underused features in Palo Alto’s toolkit.

Pillar 2 — Least Privilege Access

App-ID Based Policies

This is where most migrations from traditional firewalls feel uncomfortable — and also where the biggest security gains come from.

In a traditional firewall, a rule that allows your users to access the CRM system might look like this:

Allow | Source: 10.1.0.0/24 | Destination: 10.2.1.50 | Port: 443

That rule allows any HTTPS traffic from the user subnet to that server. Which means it also allows any other application that runs over HTTPS — because the firewall has no idea what the application actually is.

In Palo Alto with App-ID, the same rule looks like this:

Allow | Source: Users-Subnet | Destination: CRM-Server | Application: salesforce (or your specific CRM app)

Now the firewall actually understands what’s flowing through it. If someone tries to use a tunnelling tool over port 443 to bypass other controls — it gets blocked, because it doesn’t match the allowed application.

Migrating to App-ID based policies on an existing network requires patience. You can’t do it all at once without risk. The approach I use is — run the Security Policy Optimizer in Panorama, which analyses your existing rules and tells you what applications are actually being used. Use that data to build your App-ID rules, then run both the old and new rules in parallel (with logging on both) for a period before cutting over.

It’s not fast. But it’s the right way to do it.

Eliminating Broad Rules

Least privilege means being honest with yourself about how permissive your policy actually is.

Go through your security policy and look for rules with “any” in the application or service field. Each one is a question: is this as broad as it needs to be?

Some will be legitimate. Management traffic, for example, might genuinely need to be broad. But most broad rules exist because they were quick to create and nobody narrowed them down afterwards.

Tighten them. One at a time, methodically, with testing. It’s unglamorous work. It’s also some of the highest-value security work you can do.

Pillar 3 — Assume Breach

Zone-Based Segmentation

Palo Alto’s zone model is a natural fit for Zero Trust segmentation. Zones are logical groupings of interfaces or subinterfaces, and all traffic between zones goes through the firewall and is subject to security policy.

The key is being intentional about your zone design. In a Zero Trust architecture, zones should reflect trust levels and business function — not just network topology. Your user zone, your server zone, your OT zone, your DMZ — these are different trust domains, and traffic between them should be explicitly permitted, not implicitly allowed.

I’ve seen environments where everything is in two zones — “inside” and “outside” — and there’s a broad allow rule on inside-to-inside traffic. That is the opposite of Zero Trust. If an attacker compromises any machine inside the network, they can reach everything else inside the network freely.

Start with more granular zones than you think you need. You can always merge zones later. It’s much harder to split them.

Micro-Segmentation with Panorama

Across a multi-site environment — which is most enterprise environments — Panorama is what makes consistent Zero Trust enforcement possible.

Without Panorama, you’re managing security policy on each firewall individually. Which means your Zero Trust architecture is only as good as the least-maintained firewall in your estate. One firewall that gets a “temporary” broad rule that never gets cleaned up can undermine your entire segmentation strategy.

With Panorama, you define your policy centrally and push it everywhere. Deviations from the standard get flagged. Changes go through a proper process. The policy is consistent.

This is particularly important for the “assume breach” pillar. Consistent segmentation means that if one site is compromised, the attacker’s lateral movement is constrained by the same policies as every other site. There’s no “loose” firewall that becomes the pivot point for moving through the rest of the network.

Pillar 4 — Continuous Verification

Dynamic Address Groups

Most security policies are static — they reference specific IP addresses or subnets. Dynamic Address Groups (DAGs) change that.

With DAGs, you register tags against IP addresses — either manually, via API, or through log forwarding — and your security policy references the tag rather than the IP. When an IP gets tagged, it’s automatically included in the relevant policy. When the tag is removed, it’s automatically excluded.

The most powerful use case for Zero Trust is automated quarantine. You can configure your SIEM or your EDR to register a “quarantine” tag against a compromised IP via the Palo Alto API. The moment that tag is registered, the firewall automatically restricts that IP’s access — no manual intervention, no change request, no delay. The response is automatic and immediate.

That’s what “continuous verification” looks like in practice. Access isn’t just granted once at login — it’s continuously evaluated, and it can be revoked automatically when something changes.

Security Profiles

Every security policy rule in Palo Alto should have a security profile group attached to it. Antivirus, anti-spyware, vulnerability protection, URL filtering, file blocking, WildFire — these are your continuous inspection layers.

The common mistake is applying security profiles only on internet-facing rules. In a Zero Trust architecture, you apply them on internal traffic too. Because “assume breach” means assuming that lateral movement is happening, and you want to detect it when it does.

Yes, this adds processing overhead. Modern Palo Alto hardware handles it well. And the visibility you get in return — being able to see malicious activity on internal traffic, not just internet traffic — is worth it.

The Honest Reality of Zero Trust Implementation

I want to finish with something practical, because Zero Trust can feel overwhelming when you look at it as a complete destination rather than a direction.

You’re not going to implement Zero Trust in a quarter. Probably not in a year if you’re starting from a traditional perimeter architecture. The organisations I’ve seen try to do it all at once usually end up breaking things and then rolling back to something that looks like their original architecture with a few extra labels on it.

The way it actually works is incremental:

Start with visibility. Before you can enforce Zero Trust, you need to understand what’s actually happening on your network. Turn on logging. Deploy User-ID. Enable App-ID and watch what it tells you about your traffic. This phase alone is valuable — most organisations are surprised by what they find.

Segment the highest-risk areas first. You don’t have to do everything at once. Pick the most critical assets — the ones where a breach would hurt the most — and build proper Zero Trust controls around those first. Get that right, then expand.

Fix the broad rules. Go through your policy and tighten what you can tighten. This is foundational. You can’t build Zero Trust on top of a policy full of any-any rules.

Build the processes to maintain it. Zero Trust isn’t a project with an end date. It’s an ongoing posture. You need change management processes, regular policy reviews, and someone who owns the security architecture. Without that, what you build will gradually degrade back toward the perimeter model.

Zero Trust is a direction, not a destination. Start moving. Every step matters.

Majid Ahmed — CCIE #55880 | CISSP | PCNSE | Senior Network & Security Engineer linkedin.com/in/majid-information-security